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(57) ABSTRACT 

A system and method for searching for documents within 
spaces in a distributed computing environment are provided. 
A client sends a lookup message to a space which stores 
documents. The lookup message may specify desired 
characteristics, such as a name or partial XML schema, of 
the stored documents. The documents may include XML 
service advertisements and XML device advertisements as 
well as general-purpose XML documents. A set of zero or 
more documents which match the lookup message are 
discovered. In one embodiment, the lookup message may 
include a desired name. If the lookup message includes both 
a desired name and a desired schema, the set of discovered 
documents may include both discovered documents having 
a name that matches the desired name and discovered 
documents having a schema that matches the desired 
schema. If the lookup message includes neither a desired 
name nor a desired schema, the set of discovered documents 
may include substantially all the documents stored in the 
space. After the matching documents are found, the space 
may send a lookup response message to the client. For each 
discovered document, the lookup response message may 
include a name and an advertisement. Each advertisement 
may include information which is usable by the client to 
obtain the respective discovered document or access the 
resource (e.g., a service) that the document advertises. The 
advertisements and messages may be expressed in a data 
representation language such as XML. 
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MECHANISM AND APPARATUS FOR USING 
MESSAGES TO LOOK UP DOCUMENTS 
STORED IN SPACES IN A DISTRIBUTED 
COMPUTING ENVIRONMENT 

PRIORITY INFORMATION 

This application claims benefit of priority to the following 
provisional applications, each of which is hereby incorpo- 
rated by reference in its entirety: 

Serial No. 60/202,975 filed May 9, 2000 titled Distributed 
Computing Environment; 

Serial No. 60/208,011 filed May 26, 2000 titled Distrib- 
uted Computing Environment; 

Serial No. 60/209,430 filed June 2, 2000 titled Distributed 
Computing Environment; 

Serial No. 60/209,140 filed June 2, 2000 titled Distributed 
Computing Environment; and 

Serial No. 60/209,525 filed June 5, 2000 titled Distributed 
Computing Environment. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates to distributed computing environ- 
ments including Web-centric and Internet -centric distributed 
computing environments, and more particularly to a hetero- 
geneous distributed computing environment based upon a 
message passing model for connecting network clients and 
services. 

2. Description of the Related Art 

Intelligent devices are becoming more and more common. 
Such devices range from smart appliances, personal digital 
assistants (PDAs), cell phones, lap top computers, desktop 
computers, workstations, mainframes; even, super comput- 
ers. Networks are also becoming an increasingly common 
way to interconnect intelligent devices so that they may 
communicate with one another. However, there may be large 
differences in the computing power and storage capabilities 
of various intelligent devices. Devices with more limited 
capabilities may be referred to as small footprint devices or 
"thin" devices. Thin devices may not be able to participate 
in networks interconnecting more capable devices. 
However, it may still be desirable to interconnect a wide 
variety of different types of intelligent devices. 

The desire to improve networking capabilities is ever 
increasing. Business networks are expanding to include 
direct interaction with suppliers and customers. Cellular 
phones, personal digital assistants and Internet-enabled 
computers arc commonplace in both business and the home. 
Home networks are available for interconnecting audio/ 
visual equipment such as televisions and stereo equipment to 
home computers, and other devices to control intelligent 
systems such as security systems and temperature control 
thermostats. High bandwidth mediums such as cable and 
ASDL enable improved services such as Internet access 
video on demand, e-commerce, etc. Network systems are 
becoming pervasive. Even without a formal network, it is 
still desirable for intelligent devices to be able to commu- 
nicate with each other and share resources. 

Currently, traditional networks are complex to set up, 
expand and manage. For example, adding hardware or 
software to a network often requires a network administrator 
to load drivers and configure systems. Making small 
changes to a network configuration may require that the 
entire network be brought down for a period of time. Also, 
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certain intelligent devices may not support the necessary 
interfaces to communicate on a given network. 

What is needed is a simple way to connect various types 
of intelligent devices to allow for communication and shar- 

5 ing of resources while avoiding the interoperability and 
complex configuration problems existing in conventional 
networks. Various technologies exist for improving the 
addition of devices to a network. For example, many modern 
I/O buses, such as the Universal Serial Bus, 1394 and PCI, 

10 support plug and play or dynamic discovery protocols to 
simplify the addition of a new device on the bus. However, 
these solutions are limited to specific peripheral buses and 
are not suitable for general networks. 

A more recent technology, Jini from Sun Microsystems, 

35 Inc., seeks to simplify the connection and sharing of devices 
such as printers and disk drives on a network. A device that 
incorporates Jini may announce itself to the network, may 
provide some details about its capabilities, and may imme- 
diately become accessible to other devices on the network. 

20 Jini allows for distributed computing where the capabilities 
of the various devices are shared on a network. The Jini 
technology seeks to enable users to share services and 
resources over a network. Another goal of the Jini technol- 
ogy is to provide users with easy access to resources 

25 anywhere on the network while allowing the network loca- 
tion of the user to change. Jini also seeks to simplify the task 
of building, maintaining and altering a network of devices, 
software and users. 

30 Jini requires that each Jini enabled device has a certain 
amount of memory and processing power. Typically, a Jini 
enabled device is equipped with a Java Virtual Machine 
(JVM). Thus, Jini systems are Java technology centered. 
Java is a high level object oriented programming language 

35 developed by Sun Microsystems, Inc. Java source code may 
be compiled into a format called bytecode, which may then 
be executed by a Java Virtual Machine. Since Java Virtual 
Machines may be provided for most computing platforms, 
Java and thus Jini provide for a certain amount of platform 

4Q independence. The Jini architecture leverages off the 
assumption that the Java programming language is the 
implementation language for the components of the Jini 
system. The ability to dynamically download and run Java 
code is central to many features of the Jini architecture. 

45 The purpose of the Jini architecture is to federate groups 
of devices and software components into a single dynamic 
distributed system. A key concept within the Jini architec- 
ture is that of a service. A service is an entity that can be used 
by a person, a program, or another service. Two examples of 

50 services are printing a document and translating from one 
word processor format to another. Jini allows the members 
of a Jini system to share access to services. Services in a Jini 
system communicate with each other by using a service 
protocol, which is a set of interfaces written in the Java 

55 programming language. Services are found and resolved in 
a Jini system by a look-up service. A look-up service maps 
interfaces indicating the functionality provided by a service 
to sets of objects that implement the service. 

Descriptive entries may also be associated with a service. 

60 Devices and applications use a process known as discovery 
to register with the Jini network. Once registered, the device 
or application places itself in the look-up service. The 
look-up service may store not only pointers to these services 
on the network, but also may store the code for accessing 

65 these services. For example, when a printer registers with 
the look-up service, it loads its printer driver and/or an 
interface to the driver into the look-up service. When a client 



05/14/2004, EAST version: 1.4.1 



US 6,6< 

3 

wants to use the printer, the driver and driver interface get 
downloaded from the look-up service to the client. This code 
mobility means that clients can take advantage of services 
from the network without pre-installing or loading drivers or 
other software. 

Communication between services in a Jini system is 
accomplished using the Java Remote Method Invocation 
(RMI). RMI is a Java programming language enabled exten- 
sion to traditional remote procedure call mechanisms. RMI 
allows not only data to be passed from object to object 
around the Jini network, but full objects including code as 
well. Jini systems depend upon this ability to move code 
around the network in a form that is encapsulated as a Java 
object. 

Access to services in a Jini system is lease based. A lease 
is a grant of guaranteed access over a time. Each lease is 
negotiated between the user of the service and the provider 
of the service as part of the service protocol. A service may 
be requested for some period and access may be granted for 
some period presumably considering the request period. 
Leases must be renewed for a service to remain part of the 
Jini system. 

FIG. 1 illustrates the basic Jini technology stack. The Jini 
technology defines a distributed programming model 12 
(supported by JavaSpaces, leases, and objectm templates). 
Object communication in Jini is based on an RMI layer 14 
over a TCP/IP capable networking layer 16. 

Jini is a promising technology for simplifying distributed 
computing. However, for certain types of devices, Jim" may 
not be appropriate. The computing landscape is moving 
toward a distributed, Web-centric service and content model 
where the composition of client services and content 
changes rapidly. The client of the future may be a companion 
type device that users take with them wherever they go. 
Such a device may be a combination of a cell phone and a 
PDA for example. It would be desirable for such devices to 
be able to communicate and share resources with more 
powerful devices as well as thinner or less powerful devices. 

Also, with the advent of the Internet and resulting explo- 
sion of devices connected to the net, a distributed program- 
ming model designed to leverage this phenomenon is 
needed. An enabling technology is needed that facilitates 
clients connecting to services in a reliable and secure 
fashion. Various clients from thick to thin and services need 
to be connected over the Internet, corporate Internets, or 
even within single computers. It is desirable to abstract the 
distance, latency and implementation from both clients and 
services. 

The key challenge for distributed computing technology 
is to be scalable from powerful thick clients down to very 
thin clients such as embedded mobile devices. Current 
distributed computing technologies, such as Jini, may not be 
scalable enough for the needs of all types of clients. Some 
devices, such as small footprint devices or embedded 
devices, may lack sufficient memory resources and/or lack 
sufficient networking bandwidth to participate satisfactorily 
in current distributed computing technologies. The low end 
of the client spectrum, including embedded mobile devices, 
often have limited or fixed code execution environments. 
These devices also may have minimal or no persistent 
storage capabilities. Most small, embedded mobile devices 
do not support a Java Virtual Machine. Most code-capable 
small clients run native code only. Also, most small devices 
have little more than flash memory or battery backed RAM 
as their sole persistent storage media. The size of the storage 
is often very small and sometimes read-only in nature. 



13,650 Bl 

4 

Furthermore, the access time of this type of storage media is 
often an order of magnitude greater than hard disk access 
time in more powerful clients. 
Existing connection technologies, such as Jini, may not be 

5 as scalable as desired because they are too big. For example, 
Jini requires that all participants support Java; however, 
many small clients may not have the resources for a Java 
Virtual Machine. Furthermore, due to its use of RMI, Jini 
requires that clients be able to download code and content. 

10 Jini may augment the existing client platform by download- 
ing new classes, which may pose security and size concerns 
for small devices such as embedded devices. Jini works by 
clients and resources communicating by passing code and 
data. When a client activates a Jini service, the service may 

15 return its results to the client, which may include a large 
amount of code or content. In Jini, a client may call a method 
and a large object may be returned, and thus downloaded. 
The client may not have the resource to accept the returned 
object. Also, RMI and Java itself require a lot of memory. 

20 Many small foot print devices may not have the resources to 
participate effectively or at all in current distributed com- 
puting technologies. 

Another concern with existing distributed computing 
technologies is that they often require certain levels of 

25 connection capability and protocols. For example, Jini 
assumes the existence of a network of reasonable speed for 
connecting computers and devices. Jini also requires devices 
to support TCP/IP network transport protocol. However, 
many smaller devices may have limited connection capa- 

30 bilities. Small devices may have high latency or low speed 
network connections and may not support TCP/IP. 

As mentioned above, Jini requires devices to support Java 
and thus include a Java Virtual Machine, which requires a 

35 certain amount of processing and storage capabilities that 
might not be present for many small devices. This also 
restricts the flexibility of Jini in that non-Java devices may 
not directly participate in a Jini system. Since Jini requires 
Java, it may be deemed a homogenous environment. 

^ However, it is desirable to have a distributed computing 
facility for heterogeneous distributed computing that scales 
from extremely small embedded devices through PDA's and 
cell phones to laptops and beyond even to the most powerful 
computers. 

45 Other heterogeneous solutions exist, such as the Common 
Object Request Broker Architecture (CORBA). CORBA is 
an architecture that enables program objects to communicate 
with one another regardless of the programming language 
they were written in or what operating system they're 

50 running on. However, CORBA does not address all of the 
connection issues that are addressed by Jini. Also, CORBA 
suffers from similar scalability problems as Jini. 

Technology such as Jini and CORBA use a code-centric 
programming model to define the interface between remote 

55 components. A code-centric programming model defines 
programmatic interfaces or API's for communication 
between remote clients or components. The API's may be 
defined in a particular programming language. The API's 
must be agreed to by all software components to ensure 

60 proper interoperability. Since all access to components is 
through the use of these standards API's, the code that 
implements these API's must be present in the client plat- 
form. The code may be statically linked into the platform or 
dynamically downloaded when needed. Many embedded or 

65 mobile devices simply cannot accept code dynamically from 
a network due to the quality control issues involved as well 
as the reliance on a single language and program execution 



05/14/2004, EAST version: 1.4.1 



US 6,643,650 Bl 



environment. Data-centric models, such as networking 
protocols, may avoid the dependence on moving code; 
however, such protocols are not rich enough to easily 
provide for distributed computing and they also lack the ease 
of programming with code and other programming features, 5 
such as type safety. 

Conventional distributed computing systems rely on the 
ability of a program executing on a first device to be able to 
remotely call a program on a second device and have the 
results returned to the first device. The Remote Procedure 10 
Call (RPC) is a basic mechanism for remotely calling a 
program or procedure. CORBA and Jini are both based on 
the ability to remotely invoke program methods. However, 
communicating by passing code or objects, such as in Jini or 
CORBA, may be somewhat complex. For example, as 15 
mentioned above, Jini uses the Java Remote Method Invo- 
cation (RMI) to communicate between services. In order for 
a client to move Java objects to and from remote locations, 
some means of serialization/deserialization is needed. Such 
current facilities in the Java Development Kit (JDK) rely 20 
upon the reflection API to determine the content of a Java 
object, and ultimately that code must consult the Virtual 
Machine. This code is quite large and inefficient. 

The fundamental problems with the current method for 
doing serialization/deserialization include its size, speed, 
and object traversal model. Code outside the JVM does not 
know the structure or graph of a Java object and thus must 
traverse the object graph, pulling it apart, and ultimately 
must call upon the JVM. Traditional serialization and reflec- 
tion mechanisms for storing and moving Java objects are 
just not practical for all types of devices, especially thinner 
devices. Some of the difficulties with Java reflection and 
serialization are that an object's graph (an object's transitive 
closure) reflection is difficult to do outside the JVM. Seri- 
alization is too large, requiring a large amount of code. Also, 
serialization is a Java specific object interchange format and 
thus may not be used with non-Java devices. 

The Jini distributed computing model requires the move- 
ment of Java objects between Java devices. Thus, the 4Q 
serialization mechanism itself is not platform independent 
since it may not be used by non-Java platforms to send and 
receive objects. Serialization is a homogenous object 
format — it only works on Java platforms. Serialization uses 
the reflection API and may be limited by security concerns, 45 
which often must be addressed using native JVM dependent 
methods. The reflection API may provide a graph of objects, 
but is inefficient due to the number of calls between the JVM 
and the code calling the reflection methods. 

The use of Java reflection to serialize an object requires an 50 
application to ping pong in and out of the JVM to pick apart 
an object one field at a time as the transitive closure of the 
object is dynamically analyzed. Deserializing an object 
using Java deserialization requires the application to work 
closely with the JVM to reconstitute the object one field at 55 
a time as the transitive closure of the object is dynamically 
analyzed. Thus, Java serialization/deserialization is slow 
and cumbersome while also requiring large amounts of 
application and JVM code as well as persistent storage 
space. 60 

Even for thin clients that do support Java, the Jini RMI 
may not be practical for thin clients with minimal memory 
footprints and minimal bandwidth. The serialization associ- 
ated with the Jini RMI is slow, big, requires the JVM 
reflection API, and is a Java specific object representation. 65 
Java deserialization is also slow, big and requires a 
serialized-object parser. Even Java based thin clients may 
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not be able to accept huge Java objects (along with needed 
classes) being returned (necessarily) across the network to 
the client as required in Jini. A more scalable distributed 
computing mechanism is needed. It may be desirable for a 
more scalable distributed computing mechanism to address 
security concerns and be expandable to allow for the passing 
of objects, such as Java objects, and even to allow for 
process migration from one network mode to another. 

Object based distributed computing systems need persis- 
tent storage. However, as discussed above, attempts at object 
storage are often language and operating system specific. In 
addition, these object storage systems are too complicated to 
be used with many small, embedded systems. For example, 
the Jini technology uses JavaSpaces as persistent object 
containers. However, a JavaSpace can only store Java 
objects and cannot be implemented in small devices. Each 
object in a JavaSpace is serialized and pays the above- 
described penalties associated with Java serialization. It may 
be desirable to have a heterogeneous object repository for 
distributed computing that may scale from small to large 
devices. 

JavaSpaces from Sun Microsystems, Inc., draws from the 
parallel processing work of David Gelernter, a computer 
science professor at Yale University. Gelernter' s set of 
functions named "Linda" create a shared memory space 
called a TupleSpace, in which results of a computer's 
processes or the processes themselves may be stored for 
access by multiple CPUs. Linda therefore provides a global 
shared memory for multiple processors. 

Another technology which extends Linda is TSpaces from 
IBM Corporation. TSpaces extends the basic Linda 
T\ipleSpace framework with real data management and the 
ability to download new datatypes and new semantic func- 
tionality. TSpaces provides a set of network communication 
buffers and a set of APIs for accessing those buffers. Like 
many of the solutions discussed above, TSpaces therefore 
uses a code-centric programming model and shares the 
drawbacks of such a model. Additionally, TSpaces is imple- 
mented in the Java programming language and therefore 
requires a Java "Virtual Machine, or other means of executing 
Java bytecode, such as a Java-capable microprocessor. 
Therefore, TSpaces may be inappropriate for small-footprint 
devices which cannot devote sufficient resources for execut- 
ing Java bytecode. 

It is desirable in object oriented distributed systems to be 
able to locate object repositories and find particular objects 
within those repositories. As mentioned above, the Jini 
look-up server may not be practical for small devices with 
small memory footprints. A more efficient mechanism for 
locating object stores may be desirable. 

Distributed object access also desires a fair and efficient 
sharing mechanism. As described above Jini currently uses 
a leasing mechanism to share objects. However, Jini leases 
are time based which may result in a number of problems. 
For example, the current object holder might have no idea 
how long to lease an object and may hold it too long. Also, 
the use of time-based leases may require that time be 
synchronized between multiple machines. Moreover time 
based leasing may require operating system support. Also, 
Jini leases are established and released via RMI. Thus, the 
Jini leasing mechanism suffers from the above-noted prob- 
lems with using RMI. Other leasing mechanisms may be 
desirable. 

Generally speaking, it is desirable for small memory foot 
print mobile client devices to be able to run a variety of 
services, both legacy and new, in a distributed environment. 
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The types of small clients may include cell phones and and services. Service providers may advertise services in a 

PDA's with a variety of different networking interfaces, space. Clients may find the advertisements in a space and 

typically low bandwidth. Often these devices have very use the information from an advertisement to access a 

small displays with limited graphics, but they could include service using an XML (extensible Markup Language) mes- 

laptops and notebook computers, which may have a larger 5 saging mechanism of the distributed computing environ- 

display and more sophisticated graphics capabilities. The meDt * Man Y SP 3 ^ ma y exist > each containing XML adver- 

services may be a wide range of applications as well as hsements that describe services or content. Thus, a space 

control programs for devices such as printers. It is desirable ma y be a repository of XML advertisements of services 

for a mobile client to be able to use these services wherever and ' or ™ L data > wnich ma y be raw data or advertisements 

they may be. 10 for data ' such ^ results * 

A mobile client will often be at a temporary dynamic In 0De embodiment, a space itself is a service Like any 

network address, so networking messages it sends cannot be a s P fi ac ^ ha f ao adver^ment, which a chen of the 

routed beyond that networking interface (otherwise there s P ace m f obtain in order lo be able to run that space 

may be collisions when two different clients on different s™. A space * own advertisement may include an XML 

networks have the same dynamic address). Mobile clients « ** ema > a credential or credentials and a URI ^niform 

often do not have the capability for a full function browser * esource IdenUfier ) wmch ind "* te how lo access * e s P ace ' 

or other sophisticated software. The displays may limit the A chent mav <; onstrucl a from a A s P ace ser T lce s adver " 

,. . r • ^ • ,• «■ tC«^-.*«««i i; Usementm order to access the space. A client of a space may 

chent from running certain applications. Traditional appli- . • , . . • f 

_ , , f j Ua*** -j ;„ t- ,f„ " itself be a service provider seeking to advertise in that space 

cation models are based on predetermined user interlace or .., , 6 _ „ r r 

j . • „ . A . . t . ,. # . - ?n or modify an existing advertisement. Or a chent of a space 

data characteristics. Any change to the application requires 2U . 

., t - c t , ,. may be an application seeking to access a service or content 

recompilation of the application. ,*,,, ^ , r 

r rr , listed by the space. Thus, spaces may provide catalysts tor 

It may be desirable for such clients to have a mechanism the interaction betwecn clients and services in the distributed 

for finding and invoking distributed applications or services. computing environment. 

The client may need to be able to run even large legacy A ce m delude a coUectioQ of named adverlise . 

applications which could not possibly fit in the chent s mems A be created ^ a si rQot adyertise _ 

memory footpnnt. As duscussed above, current technology, mcm ^ ^ ^ AddiUonal advertise . 

such as Jim may not be practical for small footpnnt devices. ^ be ^ [o a ^ advertisemenl , s namc 

The pervasiveness of mobile thin clients may also raise ^ ^ advertisement ^in the space, including 

additional needs. For example it may be desirable specifying any necessary graphing information such as a 

services based on the physical location of the user and his h lJ ch % iQ l m ^ In a pr * ferred embodiment, the structure 

mobile client. For example information about the services Qf a ^ ig ^ b ^ distribmed computing 

in a local vicinity may be very helpful, such as local cnviromnent> ^ be stmctured as , for 

restaurants, weather, traffic maps and movie info. example, a flat un-related set of advertisements or a graph of 

A distributed computing model should provide clients 35 re lated advertisements (e.g. commercial database). Since, in 

with a way to find transient documents and services. It may a preferred embodiment, the distributed computing environ- 

be desirable to have a mechanism for finding general- ment does not dictate how a space actually stores its content, 

purpose documents (including services and/or service spaces may be supp orted by small to large devices. For 

advertisements), where the documents are expressed in a example, a simple space may be tailored to fit on small 

platform-independent and language-independent typing ^ dev ices, such as PDAs. More advanced spaces may be 

such as that provided by extensible Markup Language implemented on large severs employing large commercial 

(XML). Current approaches, including lookup mechanisms databases. 

for Jini, Universal Plug and Play (UPnP), and the Service M mentioned abovej a space may contain advertisements 

Location Protocol (SLP), do not support such a general- for m the distributed computing environment. An 

purpose document lookup mechanism. For example, the Jim 45 advertisement may provide a mechanism for addressing and 

lookup mechanism is limited to Java Language typing and is accessing xrdces and/or ^Mcni within the distributed 

therefore not language-independent. UPnP and SLP support computin g environment. An advertisement may specify a 

a discovery protocol only for services, not for general- URI for a service. In some embodiments, the URI may allow 

purpose documents. for me serv j ce t0 be accessible over the Internet. An adver- 

Similarly, information about computing resources, such 50 tisement may also include an XML schema for the service. 

as printers in a particular location, may be helpful. Current The XML schema may specify a set of messages that clients 

technologies do not provide an automatic mechanism for 0 f the service may send to the service to invoke functionality 

locating services based on physical location of the client. Q f the service. The XML schema may define the clienl- 

Another need raised by thin mobile clients is that of address- service interface. Together, the URI and the XML specified 

ing the human factor. Thin mobile clients typically do not 5S j n an advertisement may indicate how to address and access 

contain ergonomic keyboards and monitors. The provision me service. Both the URI and schema may be provided in 

of such human factor services and/or the ability to locate XML as an advertisement in a space. Thus, a mechanism for 

such services in a distributed computing environment may addressing and accessing a service in a distributed comput- 

be desirable. ing environment may be published as an advertisement in a 

cnm , ADV „ ™, c ixnnrMTinM 60 s P ace * Clients may discover a space and then lookup indi- 

SUMMARY OF THE INVENTION ^ advcrtisem ^ nt for or coment . Spaces and all 

The problems outlined above are in large part solved by advertisements within a space may be addressed using URIs. 

various embodiments of a system and method for searching In one embodiment, space and advertisement names may 

for documents within spaces within a distributed computing follow URL (Uniform Resource Locator) naming conven- 

environment. A distributed computing environment may rely 65 tions. The use of URIs, e.g. URLs, for addressing spaces 

on "spaces" or object repositories to provide a rendezvous may allow spaces to be addressable throughout the Internet, 

mechanism or catalyst for the interaction between clients in some embodiments. 
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Once a client of a space finds the advertisement of a space The space service may verify if the client is allowed to 

service, that client of the space may run the space service, as instantiate the requested service according to the client's 

it would any other service. Note that the client of the space authentication token and capabilities indicated for that cli- 

service may be another service '(e.g. a service seeking to cnt - 

advertise in the space). In one embodiment, to run a space 5 Assuming the client is authorized, the space service may 

service, the client of the space may first run an authentica- also obtain a lease on the service advertisement for the client 

tion service for the space to obtain an authentication token. with the lease request time specified by the client. The space 

The authentication service may be specified in the service settee may then send a message to the client which includes 

advertisement of the space service. The client of the space the allocated lease and the service advertisement of the 

uses the authentication token, the XML schema of the space 10 service In one embodiment, the client may run an authen- 

(from space's service advertisement), and the URI of the ticalion service specified in the service advertisement and 

space (from space's service advertisement) to construct a obtaiD m authentication token. Next, the client may con- 

gate for the space. The client of the space may then run the struct a g ale for scrvice ( for example, using the authen- 

space service by using the gate to send messages to the space Ucation token and lhe XML schema and service URI from 

service 15 me advertisement). The above described communication 

„ , . . t_ t . between the client and space service is performed using the 

For embodiments employing authentication, when the VWT . c 4 , K. t , , r 4 . ° . 

t . v a \ 6 ~ .u r . %u XML messaging of the distributed computing environment, 

space service receives the first message from the client, with ™ .. t ^ t , . ■ X *a 

X ........ . , , . ■ The client may then run the service using the constructed 

the authentication token embedded, the space service uses t , v ../ ^ mi 

. , . • / -c j • .u • gate and XML messagmg. The service may similarly con- 

the same authentication service (specified in the service ° . t e & J . J ... 

. t . x \ r . t . t 4l _ ... nn struct a service gate for XML message communication with 

advertisement of the space service) to authenticate the client, 20 ^ c j j ent 

thus establishing its identity. The space service may deter- ¥ , _,. ,. .... 

mine the client's capabilities and bind them to the authen- , In one embodiment a client may interact with a space via 

tication token lookup messages to find documents within the space. A 

,. . „ client may send a lookup message to a space. The space may 

A client of a space may run various space facilities by ^ a net work-addressable storage location which is 

sending messages to the space service. In one embodiment, Me (0 slQre Qne or more documenls . ^ stored docu . 

when a client of a space sends a request to the space service, ments may be expressed in a data representation language 

it passes its authentication token in that request, so the space sucfa flS eXlensible Markup a^ge (XML). The lookup 

service can check the request against the client's specific message may specify desired characteristics of the slored 

capabilities. 3q documents. In one embodiment, the documents may include 

Each space is typically a service and may have an XML XML service advertisements and XML device advertise- 

schema defining the core functionality of the space service. ments as well as general-purpose XML documents. For 

The XML schema may specify the client interface to the example, the XML documents in the space may include the 

space service. In one embodiment, all space services may results of a service as expressed in XML. 

provide a base-level of space-related messages. The base- 35 A set of documents which match the lookup message may 

level space functionality may be the basic space function- be discovered. The discovered documents may include any 

ality that is capable of being used by most clients, including stored documen ts which meet the desired characteristics 

small devices such as PDAs. It may be desirable to provide specified in the lookup message. Zero or more stored docu- 

for additional functionality, e.g. for more advanced clients. ments may malcn the des ired characteristics. In one 

Extensions to the base-level space may be accomplished by 4Q embodiment, the lookup message may include a desired 

adding more messages to the XML schema that advertises name In one embodiment, the desired name specified in the 

the space. For example, in one embodiment, the base-level lookup message may include one or more wildcards. Each of 

messages do not impose any relationship graph upon the the Covered documents may then have a name that 

advertisements. Messages, for example, to traverse a hier- matches the desired name, and the names may identify the 

archy of advertisements may be a space extension. Provid- 45 discovered documents within the space. In one embodiment, 

ing such additional functionality may be done by providing the lookup messa g e may include a desired schema which is 

one or more extended XML space schemas or schema expressed in the data representation language. Each of the 

extensions for a space. The extended schemas may include discovered documents may have a schema or part of a 

the base schema so that clients of an extended space may schema that matches the desired schema. In one 

still access the space as a base space. 5Q embodiment, the lookup message may include both a 

In one embodiment, a space may provide a facility for a desired name and a desired schema. In this case, the set of 

client to instantiate a service advertised in the space. Service discovered documents may include both discovered docu- 

instantiation is the initialization done that allows a client to ments having a name that matches the desired name and 

be able to run a service. To instantiate a service, a client may discovered documents having a schema that matches the 

first select one of the service advertisements published in the 55 desired schema. In one embodiment, the lookup message 

space. The client may use the various facilities, such as the may include neither a desired name nor a desired schema. In 

look up facility, provided by the space to look up the various this case, the lookup message is essentially a request for all 

advertisements in the space. Then the client may request the documents in the space, and the set of discovered documents 

space to instantiate the service. may include substantially all the documents that are stored 

In one embodiment, service instantiation may include the 60 in the space, 

following actions. After the client requests the space service After the matching documents are found, the space may 

to instantiate the selected service, the space service may then send a lookup response message to the client. In one 

verify the client is allowed to instantiate the requested embodiment, the lookup response message may include the 

service. The space service may perform this verification by names of the discovered documents. In one embodiment, the 

examining the an authentication token included in the clients 65 lookup response message may include an advertisement for 

message. The authentication token is the credential the client each of the zero or more discovered documents. Each 

received when it established a session with the space service. advertisement may include information which is usable by 
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the client to obtain the respective discovered document or 
access the resource (e.g., a service) that the document 
advertises. In one embodiment, each advertisement may 
include a Uniform Resource Identifier (URI) at which the 
respective discovered document (or resource, such as a 
service, advertised by the document) is accessible. In one 
embodiment, at least one of the discovered documents may 
be an advertisement for a service. The advertisement for the 
service may include a schema, wherein the schema specifies 
one or more messages usable to invoke one or more func- 
tions of the service. The advertisements may be expressed in 
the data representation language, such as XML. In one 
embodiment, the lookup message and the lookup response 
message are expressed in a data representation language 
such as XML. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is an illustration of a conventional distributed 
computing technology stack; 

FIG. 2 is an illustration of a distributed computing envi- 
ronment programming model according to one embodiment; 

FIG. 3 is an illustration of messaging and networking 
layers for a distributed computing environment according to 
one embodiment; 

FIG. 4 is an illustration of a discovery service for finding 
spaces advertising objects or services in a distributed com- 
puting environment according to one embodiment; 

FIG. 5 illustrates client profiles supporting static and 
formatted messages for a distributed computing environ- 
ment according to one embodiment; 

FIG. 6 is an illustration of a distributed computing model 
employing XML messaging according to one embodiment; 

FIG, 7 illustrates a platform independent distributing 
computing environment according to one embodiment; 

FIG. 8 is an illustration of a distributed computing model 
in which services are advertised in spaces according to one 
embodiment; 

FIG. 9 is an illustration of a distributed computing model 
in which results are stored in spaces according to one 
embodiment; 

FIG. 10 is an illustration of client and service gates> as 
messaging endpoints in a distributed computing model 
according to one embodiment; 

FIG. lOfc is an illustration a message endpoint generation 
according to a schema for accessing a service according to 
one embodiment. 

FIG. 11a illustrates gate creation in a distributed comput- 
ing environment according to one embodiment; 

FIG. 116 illustrates gate creation and gate pairs in a 
distributed computing environment according to one 
embodiment; 

FIG. 12 is an illustration of possible gate components in 
a distributed computing environment according to one 
embodiment; 

FIG. 13 is an illustration of proxy client for a conventional 
browser to participate in the distributed computing environ- 
ment according to one embodiment; 

FIG. 14 illustrates the use of a method gate to provide a 
remote method invocation interface to a service in a distrib- 
uted computing environment according to one embodiment; 

FIG. 15 is an illustration of the use of a space in a 
distributed computing environment according to one 
embodiment; 

FIG. 16 illustrates advertisement structure according to 
one embodiment; 
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FIG. 17 illustrates one example of advertisement state 
transitions that an advertisement may undergo during its 
lifetime according to one embodiment; 

FIG. 18 is an illustration various space location mecha- 
s nisms in a distributed computing environment according to 
one embodiment; 

FIG. 19 is an illustration of space federations in a dis- 
tributed computing environment according to one embodi- 
ment; 

30 FIG. 20 is a flow diagram illustrating client formation of 
a session with a space service in a distributed computing 
environment according to one embodiment; 

FIG. 21 is an illustration of a space event type hierarchy 
5 for one embodiment; 

FIG. 22 is a flow diagram illustrating service instantiation 
in a distributed computing environment according to one 
embodiment; 

FIG. 23 is an illustration of a default space in a distributed 
20 computing environment according to one embodiment; 

FIG. 24 illustrates an example of a device bridging 
proximity-based devices onto another transport mechanism 
to allow the services provided by the proximity-based 
devices to be accessed by devices outside the proximity 
25 range of the devices, according to one embodiment; 

FIG. 25 is an illustration of the use of lease renewal 
messages in a distributed computing environment according 
to one embodiment; 

FIG. 26a is a flow diagram illustrating an authentication 
30 service providing an authentication credential to a client 
according to one embodiment; 

FIG. 26b is a flow diagram expanding on step 1002 of 
FIG. 26a and illustrating an authentication service generat- 
35 ing an authentication credential according to one embodi- 
ment; 

FIG. 27 illustrates one embodiment of a bridging mecha- 
nism; 

FIG. 28 illustrates an example of a space discovery 
40 protocol mapped to an external discovery service according 
to one embodiment; 

FIG. 29 illustrates bridging a client external to the dis- 
tributed computing environment to a space in the distributed 
computing environment according to one embodiment; 
45 FIG. 30 is an illustration of a proxy mechanism according 
to one embodiment; 

FIG. 31 illustrates one embodiment of a client with an 
associated display and display service according to one 
embodiment; 

50 FIGS. 32A and 32B illustrate examples of using schemas 
of dynamic display objects according to one embodiment; 

FIG. 33A illustrates a typical string representation in the 
C programming language; 

55 FIG. 33B illustrates an example of a conventional string 
function; 

FIG. 33 C illustrates an efficient method for representing 
and managing strings in general, and in small footprint 
systems such as embedded systems in particular according 
60 to one embodiment; 

FIG. 34 illustrates a process of moving objects between a 
client and a service according to one embodiment; 

FIGS. 35a and 35b are data flow diagrams illustrating 
embodiments where a virtual machine (e.g. JVM) includes 
65 extensions for compiling objects (e.g. Java Objects) into 
XML representations of the objects, and for decompiling 
XML representations of (Java) objects into (Java) objects; 
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FIG. 36 illustrates a client and a service accessing store FIG. 47 is a flow diagram illustrating a search for docu- 

mechanisms in the distributed computing environment, ments within a space in a distributed computing environ - 

according to one embodiment; ment according to one embodiment; and 

FIG. 37 illustrates process migration using an XML FIG. 48 is a flow diagram illustrating the addressing of a 

representation of the state of a process, according to one 5 service using an advertisement stored in within a space in a 

embodiment* distributed computing environment according to one 

FIG. 38 illustrates a mobile client device accessing spaces embodiment. 

, , , , „ i ,. f _ While the invention is susceptible to various modifica- 

ln a local distributed computing network, according to one ... t . c ^ ... 41t _ r 

... r & j & tl0ns alternative forms, specific embodiments thereof 

' 10 are shown by way of example in the drawings and will 

FIG. 39a illustrates a user of a mobile device discovering nere j n be described in detail. It should be understood, 

the location of docking stations, according to one embodi- however, that the drawings and detailed description thereto 

ment; are not intended to timit the invention to the particular form 

FIG. 39b illustrates a mobile client device connecting to disclosed, but on the contrary, the intention is to cover all 

a docking station, according to one embodiment; J5 modifications, equivalents and alternatives falling within the 

FIG. 40a illustrates 'an embodiment of embedded devices spirit and scope of the present invention, 

controlled by a control system and accessible within the DETAILED DESCRIPTION OF EMBODIMENTS 

distributed computing environment, according to one Qp the INVENTION 

embodiment; Overview of Embodiments for Distributed Computing 

FIG. 40b illustrates a device control system connected via 20 Turning now to FIG. 2, a distributed computing environ- 

a network (e.g. the Internet) to embedded devices accessible ment programming model is illustrated. The model includes 

within the distributed computing environment, according to API layer 102 for facilitating distributed computing. The 

one embodiment; API layer 102 provides an interface that facilitates clients 

FIG. 41 is a flow diagram illustrating the spawning of a connecting to services. The API layer 102 is concerned with 

new space in a distributed computing environment accord- 25 the discovery of and the connecting of clients and services, 

ing to one embodiment; The API layer 102 provides send message and receive 

FIG. 42 is a flow diagram illustrating the secure spawning message capabilities. This messaging API may provide an 

of a new space in a distributed computing environment interface for simple messages in a representation data or 

according to one embodiment; meta-data format, such as in the extensible Mark-up Lan- 

FIG. 43 is a flow diagram illustrating a search for spaces 30 guage (XML). Note that while embodiments are described 

using a search service in a distributed computing environ- herein employing XML, other meta-data type languages or 

ment according to one embodiment; formats may be used in alternate embodiments. In some 

FIG. 44a is a flow diagram illustrating a method of storing embodiments, the API layer may also provide an interface 

results of a service in a space in a distributed computing for messages to communicate between objects or pass 

environment according to one embodiment; 35 objects, such as Java objects. API's may be provided to 

FIG. 44b is a flow diagram illustrating a method of storing discover an object repository or "space", find a particular 

results of a service in a space and notifying a client using an ob J ect ' claim and release an ob J ect > and wnte or take an 

event in a distributed computing environment according to t0 or from lhe ob J ect repository. Objects accessible 

one embodiment- through API layer 102 may be represented by a representa- 

FIG. 44c is a flow diagram illustrating a method of 40 tjon data format, such as XML. Thus an XML representa- 

sending results of a service in a message to a client in a u ° n o£ 80 ob J ect ma y be nampulated, as opposed to the 

distributed computing environment according to one 0 ^L 1 , 56 ' - . - - ™ 

embodiment* layer 102 sits on top of a messaging layer 104. The 

r-i^ amj • a _r ... t t i i £ messaging layer 104 is based on a representation data 

FIG. 44a is a flow diagram illustrating a method or , - r u vx*t i u j- f vut 

_ . to « * A . 45 format, such as XML. In one embodiment, XML messages 

returning results of a service using an advertisement in a « • . iA . t . 

.... & , & . j • are generated by messaging layer 104 according to calls to 

distributed computing environment according to one ~ nT , A* ™ " D , a 

embodiment- & the API layer 102. The messaging layer 104 may provide 

' „ . . - defined static messages that may be sent between clients and 

FIG. 44e is a flow diagram illustrating a method of Messaging layer 104 may also provide for dynami- 

returning results of a service using an advertisement sent to 5Q caU eneraled roeS sages. In one embodiment, an object, 

a client in a message in a distributed computing environment sucfa as a Jaya objectj may be dynamically converted into an 

according to one embodiment; XML representatioD . ^ messaging layer 104 may then 

FIG. 44/ is a flow diagram illustrating a method of send the XML object representation as a message, 

returning results of a service using an advertisement stored Conversely, the messaging layer 104 may receive an XML 

in a space in a distributed computing environment according 55 representation of an object. The object may then be recon- 

to one embodiment; stituted from that message. 

FIG. 44g is a flow diagram illustrating a method of [ n one embodiment, messages sent by messaging layer 

returning results of a service using an advertisement stored 104 may include several basic elements, such as an address, 

in a space and notifying a client using an event in a authentication credentials, security tokens, and a message 

distributed computing environment according to one 60 body. The message system transmission and receive mecha- 

embodiment; nisms may be completely stateless. Any notion of state may 

FIG. 45 is a flow diagram illustrating a method of sending be embedded in the message stream between sender and 

results of one service to another service in a distributed receiver. Thus, message transmission may be done asyn- 

computing environment according to one embodiment; chronously. In a preferred embodiment, no connection 

FIGS. 46a and 46b are illustrations of a search service and 65 model is imposed. Thus, transports such as TCP are not 
its interaction with a client in a distributed computing required. Also, error conditions may be limited to non- 
environment according to one embodiment; delivery or security exceptions. • 
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Messaging layer 104 sits on top of a message capable 
networking layer 106. In a preferred embodiment, messag- 
ing layer 104 does not require that a particular networking 
protocol be used. TCP/IP and UDP/IP are examples of 
message capable protocols that may be used for message 
capable networking layer 106. However, other more spe- 
cialized protocols such as the Wireless Application Protocol 
(WAP) may also be used. Other possible message protocols 
are IrDA and Bluetooth network drivers beneath the trans- 
port layer. Networking layer 106 is not limited to a single 
reliable connection protocol, such as TCP/IP Therefore, 
connection to a larger variety of devices is possible. 

In one embodiment, message capable network layer 106 
may be implemented from the networking classes provided 
by the Java2 Micro Edition (J2ME) platform. The Java2 
Micro Edition platform may be suitable for smaller footprint 
devices that do not have the resources for a full Java 
platform or in which it would not be efficient to run a full 
Java platform. Since J2ME already provides a message 
capable family of networking protocols (to support sockets), 
it follows that for the small footprint cost of adding mes- 
saging layer 104, distributing computing facilities may be 
provided for small devices that already include J2ME. 

Message capable networking layer 106 may also be 
provided by the Java Development Kit's (JDK) java.net 
networking classes. Alternatively, any message capable net- 
working facilities may be used for message capable net- 
working layer 106. In a preferred embodiment, a reliable 
transport is not required, thus embedded devices supporting 
an unreliable data gram transport such as UDP/IP may still 
support the messaging layer. 

Thus, thin clients may participate in a distributed com- 
puting environment by simply adding a thin messaging layer 
104 above a basic networking protocol stack. As shown in 
FIG. 3, a basic system includes messaging layer 104 on top 
of a networking layer 106. The networking layer may 
provide for reliable messages, e.g. TCP, or unreliable 
messages, e.g. UDP. The Internet Protocol (IP) is shown in 
FIG. 3 as an example of protocol that may be used in 
networking layer 106. However, the distributed computing 
environment does not require IP. Other protocols may be 
used in the distributed computing environment besides IP.A 
network driver such as for Ethernet, Token Ring, Bluetooth, 
etc. may also be part of the networking layer. Many small 
clients already provide a network driver and transport pro- 
tocol such as UDP/IP. Thus, with the addition of the thin 
XML based messaging layer, the device may participate in 
the distributed computing environment. 

Thus, the foundation for the distributed computing envi- 
ronment is a simple message passing layer implemented on 
top of reliable connection and/or unreliable data grams. The 
messaging technology is very different from communica- 
tions technologies employed in other distribution computing 
systems, such as Jini which employs the Java remote method 
invocation (RMI). The message passing layer 104 supports 
an asynchronous, stateless style of distributed programming, 
instead of the synchronous, state-full style predicated by 
RMI. Moreover, message passing layer 104 is based on a 
data representation language such as XML and thus copies 
data, but not code, from source to destination, unlike RMI. 
By using a representation data language, such as XML, 
messaging layer 104 may interoperate with non-Java and 
non-Jini platforms in a seamless fashion because Java code 
is not assumed on the sending or receiving end of a message. 
Moreover, unlike RMI, messaging layer 104 does not 
require a reliable transport mechanism such as TCP/IP. 

The message passing layer may provide simple send( ) 
and receive( ) methods to send a message specified as an 
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array or string of bytes, for example. The send( ) method 
may return immediately, performing the data transfer asyn- 
chronously. For flow control purposes a callback method 
may be supplied which is invoked in the event that the send( 

5 ) method throws an exception indicating it cannot handle the 
send( ) request. The receive( ) method may be synchronous 
and may return the next available message. 

The message passing layer may also provide methods for 
storing XML representations of objects, services and content 

10 in "spaces". A space is named and accessed on the network 
using an URI (Uniform Resource Identifier). The URI may 
be a URL (Uniform Resource Locator) or a simpler version 
of a URL. In some embodiments, the URL class may be too 
large. For such embodiments a simpler resource locator may 

15 be used that specifies the protocol for moving the messages 
between client and server, protocol dependent host ID, 
protocol dependent port ID, and a space name. 

An XML representation of an object may be added to a 
space using a write( ) method provided by the messaging 

20 layer. In one embodiment, the object and the client-specified 
name may be supplied as parameters. In one embodiment, 
the write method may translate the object into its XML 
representation. A take( ) method may be provided to return 
the object and remove it from the space. A find( ) method 

25 may be provided to return a specified object from its XML 
representation in a space. The find( ) method may also be 
used to return an array of matching objects in a space given 
a class. Each of these space methods is implemented using 
the message -passing layer. A lease mechanism may also be 

30 provided, as described in more detail below. 

A discovery service may be provided for clients as a 
general search facility that may be used by a client to locate 
a particular space. Rather than attempt to define a compli- 
cated search protocol which may not be feasible for a thin 

35 client to implement, the discovery service may onload the 
actual search to XML-based search facilities, leaving the 
discovery service simply to provide interface functionality 
to the client. The approach is illustrated in FIG. 4. In one 
embodiment, the discovery service receive( ) a string speci- 

40 fying something to locate, and it sends an XML message to 
a known discovery front-end (perhaps found in a default 
space), which then parses the string and makes a correspond- 
ing XML query to a search facility (which may be an internet 
search facility). The discovery front-end may parse what it 

45 obtains from the search facility and repackage it as an array 
of strings (each string may be a URI for each found space) 
which it may send in an XML message to the client. It should 
be noted that the discovery service does not require that the 
messaging be atop a connection-oriented transport. Thus, 

50 even very thin clients that do not have TCP could use such 
a discovery service. The discovery front-end makes it pos- 
sible for the client to discover spaces without a browser or 
search facility on the client. The client only needs a simple 
facility that sends a string that specifies keywords to the 

55 front-end, which interfaces with a search facility. 

A client may be any platform that can send a message 
using at least a subset of the API and messaging layers. In 
one embodiment the API layer may provide for both static 
(or raw) and formatted (or cooked) messages. A server may 

60 be any platform capable of receiving and fulfilling message 
requests. An explicit raw message send may be provided that 
moves a series of bytes from a client to a server or to another 
client. The message type may be specified as reliable (e.g. 
TCP) or unreliable (e.g. UDP). The smallest of devices may 

65 use raw unreliable message passing as their sole means of 
participation in the distributed computing environment. The 
device may use these messages to announce its presence and 
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its status. Such small devices may also receive raw messages 112 throughout a network. The network may be a wide area 

to implement certain functions, such as turning a feature on network such as the Internet. The network may also be a 

or off. combination of networks such as a local area network 

Message-based services such as spaces may send and (LAN) connected to a wireless network over the Internet. As 

receive reliable formatted messages. A space message may 5 shown in FIG. 8, a service 112 publishes an advertisement 

be formatted with a well-defined header and with XML. In 132 for itself (represented in XML) in a space 114. The 

one embodiment, a formatted message send may occur when advertisement 132 specifies the service's XML schema and 

a client uses a space method to claim, write, or take objects URI address. Then, a client 110 may look up the advertise - 

from a space. The message contents may be dynamically ment 132. The client 110 may use the advertisement 132 to 

formatted in XML and contain well-defined headers. FIG. 5 10 instantiate a gate 130. The gate 130 allows the client 110 to 

illustrates client profiles supporting formatted and static run the service 112, by sending (and receiving) XML mes- 

messages. By using static messages, small devices may use sages to (and from) the service 112. 

a smaller profile of code to participate in the distributed Some results of running a service may be returned to the 

computing environment. For example, a small device could client in an XML message. However, since other results may 

just send basic pre-defined messages. Depending on the is be too large for a small client to receive and consume at 

client, the static pre-defined messages may consume a small once, a service 112 may put those results or an XML 

amount of memory (e.g. <200 bytes). Static messages may representation of the results 134 in a space 114, as shown in 

also be an option even for larger devices. On the other hand, FIG. 9, and return them by reference (in an XML message) 

the dynamic XML messages may be useful when object to the client 110, rather than by value. Examples of methods 

values are not known at compile time. 20 of returning a reference to results include, but are not limited 

Turning now to FIG. 6, a distributed computing model is to: returning in the message a URI referencing the results in 

illustrated that combines a messaging system with XML a space, and: returning in the message an XML document 

messages and XML object representation. The platform including the URI of the results. Later, the client 110 may 

independence of XML may be leveraged so that the system access the results, or pass them by reference to another 

may provide for a heterogeneous distributed computing 25 service. The space in which results may be stored may be 

environment. Thus, client 110 may be implemented on different from the space in which the service is advertised, 

almost any platform instead of a particular platform like In one embodiment, the distributed computing environ- 

Java. The messaging system may be implemented on any ment uses XML for content definition, advertisement and 

network capable messaging layer, such as Internet protocols description. New content for the distributed computing 

(e.g. TCP/IP or UDP/IP). Thus, the computing environment 30 environment (messages and advertisements for example) are 

may be distributed over the Internet. In one embodiment, the defined in XML. Existing content types (e.g. developed for 

messaging system may also use shared memory as a quick other environments) may also be described using XML as a 

interprocess message passing mechanism when the client level of indirection (meta-data). XML provides a powerful 

and/or space server and/or service are on the same computer means of representing data throughout a distributed system 

system. The distributed computing model of FIG. 6 may also 35 because, similar to the way that Java provides universal 

be very scalable because almost any size client can be code, XML provides universal data. XML is language 

configured to send and/or receive XML messages. agnostic and is self-describing. The XML content may be 

As shown in FIG. 6, two kinds of software programs may strongly typed and validated using schemas. Using a pro- 
run in the distributed computing model: services 112 and vided XML schema, the system may ensure that only valid 
clients 110. Services 112 may advertise their capabilities to 40 XML content is passed in a message. XML content may also 
clients wishing to use the service. The services 112 may be translated, into other content types such as HTML and 
advertise their capabilities in spaces 114. As illustrated in WML. Thus, clients that do not understand XML may still 
FIG. 7, clients 110 and services 112 may or may not reside use the distributed computing environment services, 
within the same network device. For example, devices 120 In one embodiment, the distributed computing environ - 
and 124 each support one client, whereas service 112a and 45 ment messages may define the protocol used to connect 
client 110b are implemented in the same device 122. Also, clients with services, and to address content in spaces and 
as illustrated in FIG. 7, no particular platform is required for stores. The use of messages to define a protocol allows many 
the devices to support the clients and services. For example, different kinds of devices to participate in the protocol. Each 
device 120 is Java based, whereas device 124 provides a device may be free to implement the protocol in a manner 
native code runtime environment. 50 best suited to its abilities and role. For example, not all 

A device may be a networking transport addressable unit. devices are capable of supporting a Java runtime environ- 

Example devices include, but by no means are limited to: ment. The distributed computing environment protocol defi- 

PDAs, cellular/mobile phones, notebook computers, nition does not require nor imply the use of Java on a device, 

laptops, desktop computers, more powerful computer Nor does it preclude it. 

systems, even supercomputers. Both clients and services 55 A service's capabilities may be expressed in terms of the 

may be URI-addressable instances of software (or firmware) messages the service accepts. A service's message set may 

that run on devices. Using the distributed computing envi- be defined using an XML schema. An XML message schema 

ronment architecture, a client may run a service. A space is defines each message format using XML typed tags. The tag 

a service that manages a repository of XML documents. usage rules may also be defined in the schema. The message 

Even though it is redundant, the term, space service, may be 60 schema may be a component of an XML advertisement 

used herein for readability. A software component may be along with the service's message endpoint used to receive 

both a client and service at different times. For example, messages. The distributed computing environment may 

when a service uses a space (e.g. to advertise itself), that allow clients to use all or some subset of a service's 

service is a client of the space. capabilities. Security policies may be employed to enforce 

FIG. 8 illustrates the basic model of the distributed 65 the set of capabilities given to a client. For example, once a 

computing environment in one embodiment. The distributed set of capabilities has been given to a client, the client may 

computing environment may connect clients 110 to services not change that set without proper authorization. This model 



05/14/2004, EAST Version: 1.4.1 



US 6,643, 

19 

of capability definition allows for services levels that range 
from a base set of capabilities to an extended set. Extensions 
may be added to services by adding to the number of 
recognized messages. 

In one embodiment, all operations in the distributed 5 
computing environment are embodied as XML messages 
sent between clients and services. Storage (both transient 
and persistent) providers are examples of services that 
enable clients and services to store, advertise, and address 
content. Clients and services may find each other and broker 10 
content using a transient storage space. Services may place 
a content or service advertisement in a space. The adver- 
tisement may describe the content type or the capabilities of 
the service. Clients may subsequently browse spaces look- 
ing for advertisements that match a desired set of capabili- is 
ties. When a client finds a matching advertisement, a com- 
munication channel may be established which may enable 
bidirectional message passing to the service backing the 
advertisement. In one embodiment, the communication 
channel is authenticated. Results (which are just another 20 
content type) from service operations may be returned 
directly to the client in a response message, advertised and 
stored in a space, or advertised in a space, but stored 
persistently. Stored results may be addressed using a URI 
(e.g. returned in the response message) and may have an 25 
associated authentication credential. 
Message Gates 

As discussed above, the distributed computing environ- 
ment leverages off the use of a data description language, 
such as XML. XML may be used to describe a target entity 30 
(e.g. document, service, or client) to an extent such that code 
may be generated to access that entity. The generated code 
for accessing the target entity may be referred to as a 
message gate. Thus, in one embodiment, the distributed 
computing environment differs from other distributed com- 35 
puting environments in that instead of passing the necessary 
code between objects necessary to access the other object, 
the environment provides access to XML descriptions of an 
object or target so that code may be generated based on the 
XML description to access the target. The distributed com- 40 
puting environment may use an XML schema to ensure type 
safety as well as a programming model (e.g. supported 
messages) without having to agree upon language specific 
APIs, just XML schemas. 

Code generated from an XML schema may also incorpo- 45 
rate the language, security, type safety, and execution envi- 
ronment characteristics of the local platform. The local 
platform may thus have control over the generated code to 
ensure that it is bug-free and produces only valid data 
according to the schema. The generated code may conform 50 
to the client's code execution environment (e.g. Java, C++, 
Smalltalk), as well as its management and security frame- 
work (Web-server and/or operating system). 

Note that the distributed computing environment does not 
require that code generated from an XML schema be gen- 55 
e rated "on the fly" at runtime. Instead, some or all of the 
code may be pre-generated for categories (or classes) of 
services, and then linked-in during the platform build pro- 
cess. Pre-generation of code may be useful for some clients, 
such as embedded devices, where certain XML schemas are 60 
already known. In one embodiment, some or all of the code 
doesn't actually have to be generated at all. A private 
code-loading scheme (within the client) might be used in 
one embodiment to augment the generation process. In 
addition, the distributed computing environment may 65 
specify, in some embodiments, an interface to download 
code for additional features in accessing a service (see, e.g., 
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message conductors described below). Typically, such 
downloaded code may be small and the client may have the 
option to download the code or not. 

The phrase "generated code" may refer to code that 
originates within the client under the control of the client 
code execution environment, or to code that is generated 
elsewhere (such as on the service system or on a space 
service system) and that may be downloaded to the client 
system after generation. Binding time, however, may be at 
runtime. At runtime, the generated code may be bound to a 
service address (URI), so that a message may be sent to that 
service instance. 

As discussed above, the interface to any service in the 
distributed computing environment may be specified by an 
XML schema, defining the set of messages that a client may 
send (and receive from) that service. As illustrated in FIG. 
10, the client 110 and service 112 may each construct a 
message gate 130 for communicating according to the 
specified XML schema. From the XML schema advertised 
for the service 112 (and possibly other information in the 
service advertisement), a message gate 130a or 130ft may be 
constructed by the client 110a or 1106 respectively. A 
corresponding message gate 130c generated from the same 
XML schema may also exist on the service 112a. A gate 130 
is a message endpoint that may send and/or receive type-safe 
XML messages, and that may verify the type correctness of 
XML messages when sending and/or receiving the mes- 
sages. The message gate may also provide for authentication 
and/or other security mechanisms to ensure that the message 
endpoint is secure. In one embodiment, message gates are 
always secure. 

The distributed computing environment messaging layer 
described above may be coupled to or may be part of the 
gate. The messaging layer asynchronously delivers an 
ordered sequence of bytes, using a networking transport, 
from the sender to the receiver, maintaining the notion on 
both the sender and receiver that this sequence of bytes is 
one atomic unit, the message. The distributed computing 
environment does not assume that the networking transport 
is IP-based. Instead, the messaging layer may sit atop 
whatever networking transport layer is supported by the 
device. 

Message gates may provide a mechanism to send and 
receive XML messages between clients and services. The 
XML messages may be "typed". For example, the messages 
may include tags to indicate if a message data field is, e.g., 
integer, floating point, text data, etc. A message gate may be 
constructed to verify the type correctness of messages sent 
or received. A message gate also may authenticate (e.g. 
securely identify) the sender of a received message. An 
XML schema may be provided for a service that describes 
the set of messages accepted by the service and/or sent by 
the service. A message gate may verify the correctness of 
messages sent or received according to the XML schema for 
which the gate is constructed. 

Agate may be constructed as a single atomic unit of code 
and data that performs type verification and/or message 
correctness verification and/or sender identification for mes- 
sages between a client and a service in the distributed 
computing environment. In one embodiment, once the 
atomic unit of code and data for a message gate has been 
created, it cannot be altered as to its typing, message 
descriptors, and sender identification. In another 
embodiment, the gate may be modified as to the contents of 
the message schema after the gate is created, including 
deleting, adding, or modifying messages in the message 
schema. 
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A message gate is the message endpoint for a client or 
service in the distributed computing environment. A mes- 
sage gate may provide a secure message endpoint that sends 
and receives type-safe XML messages. Messages gates may 
allow clients and services to exchange XML messages in a 
secure and reliable fashion over any suitable message: 
transport (e.g. HTTP). For a client, a message gate may 
represent the authority to use some or all of a service's 
capabilities. Each capability may be expressed in terms of a 
message that may be sent to a service. Each such message 
may be sent through a client message gate which may verify 
the correctness of the message. The message may be 
received by a service message gate which may authenticate 
the message and verify its correctness. 

A message gate may provide a secure communication 
endpoint that type checks XML messages. As further dis- 
cussed below, a message gate may also provide a mechanism 
to restrict the message flow between clients and services. In 
one embodiment when a client desires to access a service, a 
client and service message gate pair is created, if not already 
existing. In one embodiment, the service message gate may 
be created when the service receives a first message from the 
client message gate. In one embodiment, one or more 
service message gates may be created when the service is 
initialized, and may be used to pair with client message gates 
when created. The creation of a message gate may involve 
an authentication service that may negotiate the desired level 
of security and the set of messages that may be passed 
between client and service. In one embodiment, the authen- 
tication service may accept a client ID token (also referred 
to as a client token), a service ID token (also referred to as 
a service token), and a data representation language message 
schema that describes the set of data representation language 
messages that may be sent to or received from the service. 
For example, messages may be described that may be sent 
from a client to a service to invoke the service or to invoke 
aspects of the service. Messages may also be described that 
are to be sent from the service, such as response messages 
and event notification messages. Refer to the Authentication 
and Security section below for a further discussion of how 
the authentication service may be used in the construction 
and use of message gates. 

A client message gate and a service message gate pair may 
allow messages to be sent between the client and the service. 
In one embodiment, message gates may be created that only 
send and/or receive a subset of the total set of messages as 
described in the message schema for a service. This limited 
access may be used within the distributed computing envi- 
ronment to implement a policy of least privilege whereby 
clients are only given access to specific individual message 
types, based on a security policy. Refer to the Authentication 
and Security section below for a further discussion of 
security checks for gate usage and gate creation. 

Qient and service gates may perform the actual sending 
(and receiving) of the messages from the client to the 
service, using the protocol specified in the service adver- 
tisement (URI of service in the service advertisement). The 
client may run the service via this message passing. A 
message gate may provide a level of abstraction between a 
client and a service. A client may access a service object 
through a message gate instead of accessing the service 
object directly. Since the gate abstracts the service from the 
client, the service's code may not need to be loaded, and 
then started, until the client first uses the service. 

The client gate may also perform verification of the 
message against the XML schema, or verification of the 
message against the XML schema may be performed by the 
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service gate, e.g. if the client indicates it has not yet been 
verified. In some embodiments, verification may not be 
practical for simple clients and may thus not be required at 
the client. In some embodiments, verification may be per- 

5 formed by the service. The gates may also perform authen- 
tication enablement and/or security schemes. In one 
embodiment, if a client does not support the protocol speci- 
fied in the service advertisement, then it may not be able to 
construct the right gate. To avoid this problem, service 

10 advertisements (used for gate construction) may include a 
ust of possible URIs for a service, so a variety of clients may 
be supported. 

A basic message gate may implement an API to send and 
receive messages. The API moves data (e.g. XML messages) 

is in and out of the gate, validating messages before sending 
and/ or upon receiving. In one embodiment, message gates 
may support a fixed minimum API to send and receive 
messages. This API may be extended to other features as 
discussed below. As illustrated in FIG. 106, a gate 130 may 

20 be generated according to an XML schema 132. The gen- 
erated gate code verifies messages based upon the XML 
schema. The gate may verify correct message types and/or 
content through the message API. As illustrated in FIG. 106, 
through the message API a verified message may be sent to 

25 a service. The message may be received by a corresponding 
gate at the service. In response to the message, the service 
may generate results 180. The service may return result data 
182 through its gate. The results data may be the results 
themselves or a reference to the results, such as a URI to 

30 results stored in a space. In various embodiments, the 
message API may support synchronous messages (request- 
response), asynchronous messages (response is discon- 
nected from request), unicast messages (point to point), 
multi-cast messages (broadcast), and publish and subscribe 

35 (event messages), for example. Other type of messages may 
also be supported, such as remote method invocation mes- 
sages. 

Each message sent by a gate may include an authentica- 
tion credential so that the receiving gate may authenticate 

40 the message. Each message may also include a token which 
includes information allowing the receiving gate to verify 
that the message has not been compromised or altered. For 
example, the sender may compute a hash or checksum of the 
message which may be verified by the receiver. The sender 

45 may also encrypt this token and/or the entire message using 
the sender's private key and may include in the encrypted 
message the corresponding public key so that the receiver 
may verify that the token was not changed. See the section 
below on Authentication and Security. 

50 A pair of message gates may provide a mechanism for 
communicating requests from clients to services and 
response from services to clients. Two associated message 
gate endpoints may be used to create a secure atomic 
bi-directional message channel for request-response mes- 

55 sage passing. Thus, the distributed computing environment 
may employ a message transport in which a message gate 
exists on both the client and the service sides. The two gates 
may work together to provide a secure and reliable message 
channel. 

60 Turning now to FIG. 11a, an illustration is provided for 
one embodiment showing construction of a gate 130a in a 
client 110 from a service advertisement or other service 
description 132. The client may have a gate factory 140 that 
is trusted code on the client for generating gates based on 

65 XML service descriptions. The use of the gate factory 140 
may ensure that the gate it generates is also trusted code, and 
that the code is correct with respect to the service adver- 
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tisement. As shown in FIG. Mb, a gate 130c may also be authentication service (e.g. specified by a service 

constructed at a service 112. The client gate 130a and the advertisement) to receive an authentication credential for the 

service gate 130c provide message endpoints for communi- gate being constructed. For services that do not restrict 

cations between the client and service. In one embodiment, access, a gate may be constructed without an authentication 

the pieces the gate factory needs to construct a gate 130 are 5 credential. The gates for such services may not need to send 

the XML schema of the service (from the service an authentication credential with each message since the 

advertisement) and the URI of the service (from the service service does not restrict access. The authentication service is 

advertisement). In another embodiment, an authentication an example of a service that does not restrict access, in one 

credential may also be obtained and used in gate construe- embodiment. Thus, a gate factory may be configured to 

tion by running an authentication service specified in the 10 optimize gate construction by checking whether a service 

service advertisement. restricts access. If the service does not restrict access, then 

Agate factory may provide a trusted mechanism to create the gate factory may avoid running an authentication service 
message gates. In some embodiments, in order to ensure that as part of gate construction and may avoid included provi- 
a message gate is a trusted message endpoint, the code used sions for an authentication credential as part of the con- 
to create the gate must be trusted code. A gate factory 140 15 structed gate. The gate factory may also receive or download 
may be a trusted package of code that is used to create gates. an XML message schema (e.g. specified by a service 
In one embodiment, each client and service device platform advertisement) to create a gate matching that schema. The 
that desires to send and receive messages in the distributed gate factory may also receive or download a URI for the 
computing environment may have a gate factory. In some service and/or for a service message gate for use in creating 
embodiments, gates may be pre-constructed by a separate 20 the client message gate to communicate with the URI. 
gate factory so that a device with pre-constructed gates may In addition, another gate construction optimization may 
not need a full gate factory, or may include a partial gate be employed for certain clients that do not desire to perform 
factory for binding a service URI and/or an authentication checking of messages against a service's XML schema. The 
credential to the pre-constructed gate at runtime (e.g. when client may be too thin to perform the checking or may rely 
messaging is desired). 25 on the service gate to perform the checking or may simply 

Agate factory for a device may generate gate code that choose not to perform the checking (e.g. to reduce gate 
may incorporate the language, security, type safety, and/or memory footprint). The gate factory may be configured to 
execution environment characteristics of the local device receive an indication of whether or not a gate should be 
platform. By constructing gates itself, a device has the constructed to verify messages against the provided XML 
ability to ensure that the generated gate code is bug- free, 30 schema. In some embodiments, certain clients may have a 
produces only valid data, and provides type-safety. An gate factory that does not provide for message verification 
advantage of a device generating its own gate code as against a schema for its constructed gates. In some 
opposed to downloading code for accessing a service is that embodiments, gates may be pre-constructed not to verify 
the client code management environment has the control. messages. In some embodiments, a gate maybe constructed 
The generated code may conform to the client's code 35 to verify outgoing messages only, or verify received mes- 
execution environment (e.g. Java, C++, Smalltalk), as well sages only. Thus, in some embodiments, a client may avoid 
as its management and security framework (Web-server or may chose to avoid building some or all of the gate code 
and/or operating system). Generated code is also trusted that checks the messages against the XML schema, 
code, because the client's runtime environment was In some embodiments, devices may maintain a cache of 
involved in its creation. Trusted security information there- 40 gates to avoid constructing them each time the same service 
fore may also be added by the trusted generated code. Thus, is run. For example, when a new gate is constructed by a gate 
a device may receive an XML message schema for a service factory, the gate may be maintained in a gate cache. When 
and then construct a gate based on that schema to access the the gate is no longer being used, it is kept in the gate cache 
device. The XML schema may be viewed as defining the instead of being deleted. If the gate cache becomes full, one 
contract with the service and the generated gate code as 45 or more gates may be removed from the gate cache accord- 
providing a secure way to execute the contract. Note that ing to a cache replacement algorithm, such as least recently 
open devices, in which un-trusted (e.g. downloaded) code used. When the gate factory is called to construct a gate, it 
may be run, may be configured so that gates may be first checks the gate cache to see if a matching gate already 
generated only by trusted code. Open devices may employ exists so that construction of a new gate may be avoided, 
a process model in which gates are enclosed in a protected, 50 The building of a gate may be made lightweight by 
isolated code container that is not accessible to tools, such appropriate reuse of pieces used to construct other gates, 
as debuggers, capable of discovering the gate's Certain portions of each gate may be the same, and thus may 
implementation, especially the gates authentication creden- be reused from gate to gate, such as parts of the message 
tial. verification code . Also, for some devices, common gate code 

A gate factory 140 may negotiate on behalf of a client 55 may be built into the system software for the device and 

with a service to create a gate to send messages to the shared by all gates on that device. Thus, the gate factory may 

service. Similarly, a gate may be constructed at the service avoid rebuilding this common code for each gate. Instead, 

to receive messages from the client gate and send messages the gate factory may simply bind the gate to this system 

to the client gate. Together, the client and service gates may software portion. For example, a system software portion 

form a secure bidirectional communication channel. 60 may be provided to handle the message layer over whatever 

A gate factory may provide a level of abstraction in gate transports are provided on the device, 

creation. For example, when a client desires to use a service, Space services in particular may be good candidates for 

instead of the client directly creating a gate to access the many of the gate construction optimizations described above 

service, the gate may be created by a gate factory as part of since a service gate constructed for a space service may 

instantiating the service. 65 perform many of the same functions as other service gates 

The gate factory may create or may include its own for that space service. Refer to the Spaces section below for 

trusted message gate that is used to communicate with an more information on space services. 
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In some instances, a more efficient form of method wishing to access that service. However, downloaded code 

invocation may exist. For example, if the target service runs may present size, security and/or safety risks, 

in the same Java Virtual Machine as the client application, A more detailed illustration of possible gate components 

a more efficient form of method invocation may be to create for one embodiment is shown in FIG. 12. Agate may include 

a Java dynamic proxy class for the service. In such a case, 5 its address (or name) 150, a destination gate address 152, a 

a java.lang.reflect.Method invocation may be faster than valid XML schema (or internal form thereof) 154, and a 

sending a message. A gate binding time procedure may transport URI 153. In other embodiments, a gate may also 

check for such an optimization and use it instead of running include an authentication credential 156. Some gates may 

the gate factory to create a gate or bind an existing gate. also include a lease 158 and/or a message conductor 160 to 

In one embodiment, such as for special -purpose clients or 10 verify message ordering, 

small embedded devices, the generation of gate code at A gate's name 150 may be a unique ID that will (for the 

runtime may not be desirable due to memory consumption life of the gate) refer only to it. A gate may be addressed 

and code generation time. Thus, instead of having a gate using its gate name 150. In one embodiment, gate names 

factory that generates gates at runtime, in some embodi- may be generated as a combination of a string from an XML 

ments gates may be pre-generated and built into the device. 15 schema (e.g. from a service advertisement) and a random 

For example, message gates may be generated during the number, such as a 128-bit random number. The name 150 

build of embedded software as a means of including a may allow clients and services to migrate about the network 

built-in secure message endpoint that does not have to be and still work together. In a preferred embodiment, the gate 

constructed at runtime. Thus, a client with built-in gates may address is independent of the physical message transport 

not need a full gate factory, or may require only a partial gate 20 address and/or socket layer. Thus, a gate name may provide 

factory for performing certain runtime binding to a built-in a virtual message endpoint address that may be bound and 

gate, such as for the URI and/or authentication credential. un-bound to a message transport address. In one 

A generation tool may be provided for the pre- embodiment, a gate's name may be a Universal Unique 

construction of gates. The generation tool may include an Identifier (UUID) that may, for the life of the gate, refer only 

XML parser, a code generator and a code compiler. In one 25 to it. 

embodiment, the code generator may be a Java source code Agate name may persist as long as the gate persists so that 

generator and the code compiler may be a Java code different applications and clients executing within the same 

compiler. During the build of the software for which built-in device may locate and use a particular gate repeatedly. For 

message gates is desired, the generation tool is run with example, a gate may be created for a first client process 

input from all the relevant XMLschemas for which gates are 30 executing within a device to access a service. After the first 

desired. client process has completed its activity with the service, it 

As an example, if it is desired for a device to have a may release the gate. Releasing the gate may involve 

built-in message gate that can send and receive messages un-binding the gate from the first client process's message 

from a digital camera, the build of the device software may transport address (e.g. IP and/or Port address). The gate may 

include running the gate generation tool with the camera's 35 be stored in a gate cache or repository. A second client 

XML message schema as input. The XML schema may be process executing within the same device that desires to run 

parsed by the XML parser that may convert the XML the same service may locate the gate by its name and use it 

schema into an internal form suitable for quick access during to access the service. To use the gate, the second client 

a message verification process. The tool's code generator process may bind the gate to its message transport address, 

may provide source code for a gate corresponding to the 40 so that the message endpoint for the second client process is 

camera's schema. In some embodiments, the generation tool a combination of the gate name and the second client 

may also compile the source code and the gate code may be process's transport address. In another example, a client may 

linked into the software package for the device. At runtime, receive a dynamic IP address (e.g. a mobile client). When 

the camera service may be discovered in the distributed the client's transport address changes, a gate name (or gate 

computing environment. The message URI for the camera 45 names) may be re-bound to the client's new transport 

service may be bound to the built-in gate for the camera address so that the client may still access a service(s) that 

within the device. The binding of the URI to the pre- that it previously accessed without having to relocate the 

constructed gate may be performed by a gate constructor service and recreate the gate. Agate name may also be useful 

within the device. This gate constructor may be a much for process migration. A process and any associated gates 

smaller, simpler gate factory. When the camera service is 50 may be checkpointed or saved at one node in the distributed 

instantiated, the URI for the camera service is passed to the computing environment and moved to another node. The 

gate constructor as an XML message. The gate constructor process may be restarted at the new node and the associated 

may then bind the URI to the pre-constructed gate. gates may be bound to the transport address for the new node 

TTius, a gate may be partially or fully generated at so that the process will still have access to the external 

runtime, or a gate may be pre-generated before runtime with 55 services to which it had access before being migrated. Agate 

a binding process (e.g. for a URI or credential) performed at may track the current location of another gate to which it is 

runtime. In one embodiment, a gate generation tool such as paired. Thus a service or client may be migrated and still be 

the gate factory or the generation tool for pre-constructed accessible. For example, replicated or load-balanced service 

gates may be a Java-based tool to provide some level of implementations may be abstracted from clients of the 

platform independence. Alternatively, gate generation tools 60 service by the gate. 

may be provided in any language, such as the native code for Thus, a gate name 150 provides a flexible mechanism by 

a particular device in the distributed computing environ- which to address a message endpoint in the distributed 

ment. computing environment. Agate name may be used to locate 

Note that the distributed computing environment does not and/or address a gate over a wide range of networks, from 

preclude a device from downloading part or all of a gate's 65 a local network to the Internet. Gate names may be inde- 

code. For example, in some embodiments, a service may pendent of message transport so that a message endpoint 

provide gate code that may be downloaded by a client (gate) may be moved from transport to transport by unbind- 
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ing and rebinding to different underlying transport addresses 
(e.g. IP/Port address pairs). 

In one embodiment, a gate may also be separated from a 
service so that the same gate may be used to send requests 
to different services over time. This may involve unbinding 
the gate's destination gate address 152 and binding a new 
destination gate address to the gate. 

A gate may be implemented as a layer above a device's 
transport layer (e.g. networking sockets). Each gate may 
include a transport reference 153. The gate name 150 may be 
bound to the transport reference 153 as described above. 
Multiple gates may share the same message transport. For 
example, multiple gates may have transport references 153 
to the same TCP/IP socket. By sharing the same message 
transport, the size and complexity of each gate may be 
reduced. A device in the distributed computing environment 
may have a large number of gates that need to send and 
receive messages. TTie message handling complexity for 
multiple gates may be reduced by sharing a common mes- 
sage transport. The transport reference 153 may be a trans- 
port URI (e.g. URL) or socket reference and may provide a 
mechanism for naming an underlying transport and sharing 
the transport with other gates. Multiple local gates may 
include a reference 153 to the same transport, however, each 
local gate may behave independently of the other local gates 
sending and receiving messages to and from its paired 
remote gate. 

The schema 154 may be downloaded from a space into the 
gate by the gate factory. The schema may be compiled into 
an internal form suitable for quick access during a message 
verification process. In one embodiment, the schema may 
specify two groups of messages: client service messages and 
provider service messages. The client service messages 
group includes the description of all messages that the client 
may send (that the provider supports), and the provider 
service messages group includes the description of all mes- 
sages that the provider may send (that the client receive( )). 
In one embodiment, either the client or provider may send 
a particular request to the space service to obtain a response 
message with either: the entire client service messages, the 
entire provider service messages, the entire client and pro- 
vider service messages, or a specific message of either the 
client service messages or the provider service messages. In 
addition, once a gate has been constructed, a client may 
query as to the capabilities of the service without the gate 
actually sending a message, but instead by inspecting the 
gate's set of messages. 

As described above, a message gate may verify the sender 
of the message using an authentication credential, message 
content for type safety and according to an XML schema. 
However, it may also be desirable to verify that messages are 
sent between a client and a service in the correct order. It 
may be desirable to be able to provision applications 
(services) for clients to run without any pre-existing specific 
functionality related to the application on the client (e.g. no 
GUI for the application on the client). For example, a Web 
browser may be used on a client as the GUI for a service 
instead of requiring an application-specific GUI. Of the 
possible messages in the XML schema, the client may need 
to know what message next to send to the service. It may be 
desirable for the client to be able to determine which 
message to send next without requiring the client to have 
specific knowledge of the service. In one embodiment, the 
service may continually send response messages indicating 
the next input it needs. The service would then accept only 
the corresponding messages from the client with the 
requested input specified. Other ad hoc scheme for message 
ordering may also be employed. 
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In another embodiment, a message conductor 160 may be 
employed in the gate or associated with the gate to verify the 
correct sequence of messages, as opposed to verifying each 
message's syntax (which may already be performed in the 

5 gate according to the schema). Message conductor 160 may 
provide a more general approach for application provision- 
ing. The message conductor 160 may be specified in a 
service's advertisement. The message conductor indication 
in a schema may allow code to be generated on or down- 

10 loaded to the client during gate construction, which may 
provide the choreography needed to decide which message 
to send next to the service. A message conductor may be 
implemented as a Java application, a Java Script, WML 
script, or in other programming or scripting languages. 

is In one embodiment, the message conductor may accept as 
input an XML document (e.g. from a service advertisement) 
that presents the valid order or choreography for messages 
that may be sent between a client and the service. This XML 
document may also specify user interface information and 

20 other rules. The conductor may parse this XML document 
into an internal form and enforce message ordering (and/or 
other rules) according to the enclosed ordering information. 
The conductor may prevent messages from being sent out of 
order. Or, if a message is sent out of order, an exception may 

25 be raised within the sending device. If a message is received 
out of order, the conductor may send an automatic response 
message back declaring the ordering error. The sender may 
then resend messages in the correct order. Note that in some 
embodiments, part or all of a conductor may be shared by 

30 several gates. Thus, a conductor may be linked to multiple 
gates. 

In one embodiment of a distributed computing 
environment, front ends for services (service interfaces) may 
be built in to clients. In one embodiment, the service 

35 interface may be a preconstructed user interface provided to 
the client by the service. In one embodiment, the service 
interface may be provided to the client in the service 
advertisement. The service interface may interact on the 
client with the user of the service to obtain input for running 

40 the service, and then may display results of running the 
service on the client. A "user" may be a human, embedded 
system, another client or service, etc. In one embodiment, a 
client device may not be able to provision arbitrary services, 
as the client device may only be able to run services for 

45 which it has a front end built in. In one embodiment, a 
service interface for a service may be implemented in a Web 
browser on the client. 

In one embodiment, a message conductor and/or service 
interface may be external to the gate and thus abstracted 

50 from the gate and client. The abstracted message conductor 
may provide provisioning of arbitrary services to any client 
device. In one embodiment, the message conductor may be 
written in code that may run on substantially any platform. 
In one embodiment, the message conductor may be written 

55 in the Java language. In one embodiment, the message 
conductor may not require the arbitrary downloading of 
objects, for example, Java objects, returned to the client 
device. For example, very large objects may be returned, and 
the message conductor may choose to not download these 

60 very large objects. In one embodiment, the message con- 
ductor may send XML messages to services from the client 
device on behalf of the client. The message conductor may 
interact with the user of the service to receive input and 
display results, 

65 In one embodiment, a service interface may be provided 
that interacts with the client (e.g. thru a user interface) to 
obtain all information to run the service, and then may 
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display either results of running the service or information 
regarding the location of results, as appropriate. The service 
interface may be either part of a message conductor 160 or 
may be in addition to and work with message conductor 160. 
The service interface may either be: 

1. Built in to the client device and thus run oh the client. 

2. Downloaded to the client device from the space server. 

3. Run on the space server. 

4. Run on the service provider. 

In one embodiment, to a client, the distributed computing 
environment space server must support #1 always, indicate 
if #2 is supported (by advertisement in space), indicate if at 
least one of #3 and #4 is supported. Note that whether or not 
it supports #4 depends upon whether or not the service 
provider supports #4. In one embodiment, to a service 
provider, the distributed computing environment space 
server must support #4 always and indicate if it supports #3. 

Regardless of where the service interface runs, once a 
service is activated, the service interface may interact with 
the client, displaying (remotely) requests for input on the 
client's display, and then displaying (remotely) results of 
running the service. Such interaction with the client is 
implemented in terms of XML messages, 

The service interface and/or message conductor may meet 
the needs of a client user that may have discovered a service, 
but does not want to read a typically large, dry computer 
manual to figure out how to use the service. As the service 
interface and/or message conductor interacts with the user to 
request all input that the service needs, they may even 
provide short descriptions of the input requested if the user 
requests it. Once the service interface has obtained the 
necessary information from the client, it may send XML 
messages to the service provider that runs the service. The 
ordering of the messages may be verified by the message 
conductor 160 in the gate. 

In a preferred embodiment, all messages flow through a 
gate. A gate may be configured to provide a flow control 
mechanism. For example, a service may need to handle a 
large amount of incoming and outgoing messages. Flow 
control may allow a service to keep up with high traffic 
volume. Gates may be configured to monitor messages for 
flow control tags. When a gate receives a message, it may 
examine that message for a flow control tag. The flow 
control tags may be XML tags. A message may include 
either an OFF tag or an ON tag, for example. If a received 
message includes an OFF tag, the receiving gate will stop 
sending messages to its paired destination gate. If the gate 
receives a message including an ON tag, it may resume 
sending messages. 

In some embodiments, a client may be too thin to support 
a full gate, or a client may not include software to directly 
participate in the distributed computing environment. In 
such embodiments, a server (such as the space server in 
which the service is advertised or another server) may be a 
full or partial proxy gate for the client. The server may 
instantiate a service agent (which may include a gate) for 
each service to be used by the client. The service agent may 
verify permission to send messages; send messages to the 
provider, possibly queuing them until the provider can 
accept the next one; send messages to the client, possibly 
queuing them until the client can accept the next one; and 
manage the storing of results in a result or activation space. 
See also the Bridging section herein. 

For example, as illustrated in FIG. 13, a client may be a 
conventional browser 400 that does not support gates to 
participate directly in the messaging scheme described 
above. The browser 400 may be aided by a proxy servlet 
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(agent) 402. The browser user may use a search engine to 
find a Web page that fronts (displays the contents of) a space 
advertising services within the distributed computing envi- 
ronment. The user is able to point and click on the space Web 

5 page and, with the help of the servlet, to access services. The 
Web pages may include scripts, for example, Java or WML 
scripts, which may be used in connecting the browser to the 
proxy servlet. Scripts may also be used to send messages to 
the proxy servlet. The servlet agent may translate Web page 

10 actions into messages on behalf of the browser client. These 
actions may include navigating a space, starting services, 
and returning results. Result page URIs (referencing pages 
containing XML) may be returned directly (or translated 
into HTML or WAP if needed) to the browser, for display to 

15 the user. Thus, the browser-based client does not need to 
know how to start services, nor which messages to send 
during the service usage session. For example, a user of a 
WAP browser (e.g. on a cell phone) may connect to a space 
page, browse its contents (services), and then start a service, 

20 all by pointing and clicking. The agent 402 provides the 
client interface between the conventional client and the 
distributed computing environment. 

The distributed computing environment may include sev- 
eral different types of message gates for communicating 

25 between clients and services that support different features. 
For example, as discussed above, some gates may support 
flow control or billing. Another type of message gate may 
support a form of remote method invocation. This type of 
gate may be referred to as a method gate. FIG. 14 illustrates 

30 the use of a method gate to provide a remote method 
invocation interface to a service. Method gates provide a 
method interface between clients and services. A method 
gate may be bidirectional, allowing remote method invoca- 
tions from client to service and from service to client. A 

35 method gate 172 may be generated from XML schema 
information 170 (e.g. from a service advertisement in a 
space). The XML schema information 170 includes XML 
defining a method interface(s). From this information, code 
may be generated as part of the gate for interfacing to one 

40 or more methods. Each method invocation (e.g. from a client 
application 176) in the generated code may cause a message 
to be sent to the service containing the marshaled method 
parameters. The message syntax and parameters to be 
included may be specified in the XML schema. Thus, the 

45 method gate 172 provides an XML message interface to 
remotely invoke a service method. The method gate may be 
generated on the client or proxied on a server, such as the 
space server where the service method was advertised or a 
special gateway server. 

50 A service may have a corresponding method gate that 
implements or is linked to a set of object methods that 
correspond to the set of method messages defined in the 
service's XML schema. There may be a one to one corre- 
spondence between the object methods implemented by or 

55 linked to the service's method gate and the method messages 
defined by the service's XML schema. Once a service's 
corresponding method receives a message from a client to 
invoke one of the service's methods, the service's method 
gate may unmarshal or unpack the parameters of the mes- 

60 sage invocation and then invoke the method indicated by the 
received message and pass the unmarshalled parameters. 

The method gate may provide a synchronous request- 
response message interface in which clients remotely call 
methods causing services to return results. The underlying 

65 message passing mechanics may be completely hidden from 
the client. This form of remote method invocation may deal 
with method results as follows. Instead of downloading 
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result objects (and associated classes) into the client, only a published by a service, subscribe to those events, and 

result reference or references are returned in XML distribute each event as the event is produced by the service, 

messages, in one embodiment. An object reference 178 may The set of events for a service may be described in the 

be a generated code proxy (e.g. result gate) representing the service's XML message schema. For each event message in 

real object result 180 (still stored out on the net, for 5 the XML schema, the event gate may subscribe itself as a 

example). In other embodiments, the client may choose to consumer of that event. In one embodiment, an event gate 

receive the actual result object. Also, once a client has subscribes to all events indicated by the XML schema. Each 

received a result object reference, the client may use this event message ma Y be named "s^g an XML ta S- The event 

reference to receive or manipulate the actual result object. In 8 ate ma y subscribe by sending a subscription message 

one embodiment, the result reference includes one or more 10 including the XML tag for the event to be subscribed to. 

URI's to the real result When a corresponding event occurs with the service, the 

The real result object(s) may be stored in a service results s*™** ma X ^ * n event message to subscribers indicating 

space (which also may be created dynamically by a servlet the occurrence of the event. The event message may contain 

for example). This temporary results space may act as a an XML event document and may be sent to each subscnbed 

query results cache. The results cache (space) may be is g a te. When a subscribed gate receives the event message, the 

patrolled by server software (garbage collector) that cleans- ™ L event document is removed from the message and the 

up old result areas. Results returned from each method P rocess of distribution begins. Event distribution is the 

invocation may be advertised in the results space. A result P rocess of handin g out the event document within the client 

itself may be or include a method that could then be platform. Each event consumer within the client platform 

remotely instantiated by a client, thus generating its own 20 may subscribe with the event gate for each type of event. On 

method gate. Therefore, the distributed computing environ- Java platforms, the typing system is Java (converted from 

ment may support recursive remote method invocation. tne event tv P e )- 

As mentioned above, when a client uses a method gate to ™ e evem consumer may supply an event handler call- 
remotely invoke a service method, a reference to the method back method to the event gate. The event gate may store a 
results may be returned from the service method gate instead 25 Ust of lhese subscriptions. As each event message arrives at 
of the actual results. From this reference, a result gate may the g ate ( from me Producing the event), the gate 
be generated to access the actual result. Thus, the client or traverses me Ust of clienl consumers and calls each handler 
client method gate may receive a result URI and perhaps a method > passing the XML event document as a parameter. In 
result XML schema and/or authentication credential for one embodiment, the XML event document is the only 
constructing a gate to access the remote method results. 30 parameter passed to the handler callback method. 

In one embodiment, a service gate may create a "child Ia one embodiment the event gate automatically sub- 
gate" for the results. This child result gate may share the itself for events 00 behalf of the local consumer 
same authentication credential as its parent gate. In some clients - As clients register interest with the gate, the gate 
embodiments, results may have a different set of access rc e isters inlerest with the event Producer service. A client 
rights and thus may not share the same authentication 35 ma y also ^-subscribe interest, which causes the gate to 
credential as its parent. For example, a payroll service may un-register itself with the service producing the event, 
allow a different set of users to initiate than to read the An event gate may type check the event document using 
payroll service's results (paychecks). lhe ™ L schema ^ llke a re S ular message gate does in the 

Aservice method gate may return a child result gate to the standard request-response message passing style described 

client gate as the result of the method. The client may then 40 ab ove. An event gate may also include an authentication 

use the result gate to access the actual results. In one credential in messages it sends and verify the authentication 

embodiment, the software program (client) receiving the credentials of received event messages, 

result gate cannot distinguish between the result gate and the Note that combination of the gate functionality 

result itself in which case the result gate may be an object described above may be supported in a single gate. Each 

proxy for the actual result object. The result gate may also 45 tv P e has described separately only for clarity. For 

be a method gate that supports remote method invocation to example, a gate may be a message gate, a method gate and 

result objects. In this manner, a chain of parent and child an even f g ate > and ma V su PP ort flow conlrol and resource 

method/results gates may be created. monitoring 

In one embodiment, the method gates and remote meth- Service Discovery Mechanisms 
ods may be in Java. Method results are correctly typed 50 In one embodiment, the distributed computing environ- 
according to the Java typing system. When a Java method is meDt ma y iQclud e a service discovery mechanism that 
remotely invoked as described above, the result gate may be V™vidcs methods for clients to find services and to negotiate 
cast into the Java type that matches the result type. In this lhe ri g hts to use *° m& or of a service ' s capabilities. Note 
embodiment, method gates may be used in the distributed lhat a s P ace 15 an example of a service. The service discovery 
computing environment to allow remote Java objects to 55 mechanism may be secure, and may track and match out- 
behave as local Java objects. The method invocation and g° irj g chenl requests with incoming service responses, 
result may appear the same to the client Java software A service discovery mechanism may provide various 
program whether the real object is local or remote. capabilities including, but not limited to: 

See the Spaces section below for a further discussion on Finding a service using flexible search criteria, 

the use of spaces for results. 60 Requesting an authorization mechanism, for example, an 

Message gates may also support publish and subscribe authentication credential, that may convey to the client 

message passing for events. Message gates with event the right to use the entire set or a subset of the entire set 

support may be referred to as event gates. A service's XML of a service's capabilities. 

schema may indicate a set of one or more events that may Requesting a credential, document, or other object that 
be published by the service. An event gate may be con- 65 may convey to the client the service's interface. In one 
structed from the XML schema. The event gate may be embodiment, the service's interface may include inter- 
configured to recognize some or all of the set of events faces to a requested set of the service's capabilities. 
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The tracking of discovery responses to the original The distributed computing environment may include a 

requests. In one embodiment, each client request may mechanism that may allow clients to negotiate how a service 

include a collection of data that may also be returned in f s to return results of a service invocation. In one 

matching responses, thus allowing the requests and embodiment, during a capability credential request, a means 
responses to be correlated .5 by which to choose one of the results return methods may be 

In one embodiment of the distributed computing ' , t . « ' 

environment, a service discovery mechanism may provide a conve y ed t0 ^ f moe - ^ f mce then S e ° er f a 

flexible search criteria based upon an extensible grammar. In custom advertisement that may convey to the chent 

one embodiment, a service name, service type, and other ^ ^sults mechanism to be used, as well as the service 

elements, if any, being searched for may be matched with interface. 

elements in an XML document. In one embodiment, the In one embodiment, the distributed computing environ- 

XML document is the service advertisement for the service. ment may include a mechanism for tracking service discov- 

XMLmay provide a flexible, extensible grammar for search- e ry search requests and responses to the requests. In one 

ing. XML also may provide type safety for matching ele- embodiment, search request and response messages may 

ments. In one embodiment, the service names and service mc i u d e a field that may be used to include a string or an 

types may be type checked with the element types in the « ^ document In oQe embodimenU me strin or ^ 

XML service advertisement. , , . . , , . . c . , f t ° . 

In one embodiment, a distributed computing environment docu ™ m 1Q ^ luded 10 the field of ar ^ uest m ™*& * al f° 

may include a mechanism for clients to negotiate service retumed m the res P onse messa & e - In one embodiment, the 

access rights, In one embodiment, the mechanism may be stnn S or XML document is required to be returned in the 

used to negotiate for a subset of a service's full capabilities. 20 response message. In one embodiment, the string or XML 

The result of the negotiation may be an authorization such document may include additional information inserted in or 

as an authentication credential that conveys to the client the appended to the string or document when returned in the 

right to use the requested subset of the service's capabilities. response message. In one embodiment, this mechanism may 

In one embodiment, the service discovery mechanism be used m debugging complex systems. In one embodiment, 

may allow a client to request a security capability credential 25 this mechanism may aIso provide t0 clients a met hod for 

from a service. In one embodiment the client may present cfao s ^ ic&s access ^ . of ^ 

to the service a set of desired capabilities in the form of a , l u • > *• ? ^ 

protected (secure) advertisement! The service may then d , ocumen ! 10 custom search informal.™ be^een a 

respond with a capability credential that may convey to the ch <j nt and service that mav onl y be "^erstood by the chent 

client the rights to use the requested capabilities described in and SCTV1CG - 

the protected advertisement. Matching Component (Service) Interfaces 

In one embodiment, the distributed computing environ- The distributed computing environment may provide a 

ment may include a mechanism for a client to negotiate mechanism for matching a component (for example, a 

service access rights and to then obtain a security credential service) specification interface with a requested interface, 

or document that may be used to present the service's access For examplCj a client (which may be a service) may desire 

interface to the set or subset of the service's capabilities that 35 & ^ & ^ ^ imerface requirements . Each 

were requested by the client. component may have a description of the interface to which 

In one embodiment, a chent that receives a capability ^ specification interface matching mecha- 

credential from a service may generate a custom service . r 4 . t , t i , , , 

access interface document that may be referred to as a nism may aflow a componen that bestmatches a requestor s 

"complete advertisement." In one embodiment, the com- 40 L nter£ilCB requiems to be located The speafication inter- 

plete advertisement may be an XML document. The gener- face matching mechanism may also allow for fuzzy 

ated advertisement may provide access to the service capa- matching of interface requirements. In other words, the 

bilities as granted to the client by the received capability mechanism may allow matching without requiring the exact 

credential. In one embodiment, an interface may be provided specification of all aspects of the interface, thus providing a 

by the advertisement only to the service capabilities to 45 nearest match (fuzzy) mechanism. In one embodiment, the 

which the client has been granted access by the capability specification interface matching mechanism may be imple- 

credential. In one embodiment, the client may be granted mented as a multi-level, sub-classing model rather than 

access to only required capabilities and to which the client requiring specification at a single interface level, 

has access privileges. In one embodiment, a component may use an XML 

In one embodiment, the distributed computing environ- 50 Schema Definition Language (XSDL) to describe its inter- 
ment may provide a mechanism by which a client may face. XSDL may provide a hum an-interp re table language for 
negotiate capabilities with services. In one embodiment, the describing the interface, simplifying activities requiring 
client may negotiate its capabilities to the service. The human intervention such as debugging. In one embodiment, 
service may then customize results based on the parameters the interface description may be provided as part of an 
negotiated with the client. For example, a client that is 55 advertisement (for example, a service advertisement) as 
capable of one bit display at a resolution of 160x200 may described elsewhere in this document, 
negotiate these parameters to the service, thus allowing the Using the specification interface matching mechanism, a 
service to customize results for the client. basic desired interface may be compared to a set of com- 

The following is included as an example of an XML ponent i nter face descriptions. One or more components 

capabilities message and is not intended to be limiting in any 60 matcmng the basic desired interface may be identified. The 

wav: interface descriptions may include subclass descriptions 

<type name«"Capabilities"> ^ describing more specifically the interfaces provided by the 

<element name="display" type«"string"/> components. In the search process, the class type hierarchy 

<element name="memory" type»"string7> ma y be examined to determine if a given class is a subclass 

<element nameo"mime" type-"string7> 65 Q f me search type. In one embodiment, subclasses may 

inherit properties of the base class, and thus the subclass- 

</type> specific information may not be examined in this phase. 
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Thus, the search may be performed generically. The iden- 
tified components may be searched at the next (subclass) 
level. The search may become specific to the subclass and 
may be performed by interpreting the subclass information 
included in the interface description. The search may con- 5 
tinue through one or more subclasses until one or more 
components is determined which may provide the nearest 
match to the requestor's desired interface. 

In one embodiment, an interface matching mechanism 
may provide the ability to distinguish among two or more 10 
components that implement similar interfaces. In one 
embodiment, the interface matching mechanism may pro- 
vide the ability to distinguish among different revisions of 
the same component. 

In one embodiment, a component description may be 15 
provided that includes a specification of the interface to 
which the component conforms. The component description 
may also include information about the component itself. 
The interface description and/or the component information 
may be used to differentiate among different implementa- 20 
tions of a given interface. The component descriptions may 
include a canonical identifier and version information. The 
version information may allow component revisions to be 
distinguished. In one embodiment, the component descrip- 
tion may be provided as part of an advertisement (for 25 
example, a service advertisement) as described elsewhere in 
this document. 

In one embodiment, components may be searched for a 
particular canonical identifier. Two or more components 
may be identified with matching canonical identifiers. One 30 
or more components may be selected from among the 
components with matching canonical identifiers. The selec- 
tion procedure may use an interface specification version, a 
component implementation specification, a component 
implementation specification version, other information or a 35 
combination of information from the component description 
to produce a set of one or more components that best match 
the requestor's requirements. 
Spaces 

As mentioned above, the distributed computing environ- 40 
ment relies on spaces to provide a rendezvous mechanism 
that brokers services or content to clients. FIG. 15 illustrates 
the basic use of a space 114. Service providers may advertise 
services in a space 114. Clients 110 may find the advertise- 
ments in a space 114 and use the information from an 45 
advertisement to access a service using the XML messaging 
mechanism of the distributed computing environment. Many 
spaces may exist, each containing XML advertisements that 
describe services or content. Thus, a space may be a reposi- 
tory of XML advertisements of services and/or XML data, 50 
which may be raw data or advertisements for data, such as 
results. 

A space itself is a service. Like any service, a space has 
an advertisement, which a client of the space must first 
obtain in order to be able to run that space service. A space's 55 
own advertisement may include an XML schema, a creden- 
tial or credentials, and a URI which indicate how to access 
the space. A client may construct a gate from a space 
service's advertisement in order to access the space. A client 
of a space may itself be a service provider seeking to 60 
advertise in that space or modify an existing advertisement. 
Or a client of a space may be an application seeking to 
access a service or content listed by the space. Thus, spaces 
may provide catalysts for the interaction between clients and 
services in the distributed computing environment. 65 

A space may be a collection of named advertisements. In 
one embodiment, naming an advertisement is the process of 
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associating a name string with an advertisement. The asso- 
ciation may take place upon storing an advertisement in a 
space. Removing an advertisement from a space disassoci- 
ates the name from the advertisement. A space may be 
created with a single root advertisement that describes the 
space itself. Additional advertisements may be added to a 
space. An advertisement's name may locate the advertise- 
ment within the space, including specifying any necessary 
graphing information such as a hierarchy of names. In a 
preferred embodiment, the structure of a space is not dic- 
tated by the distributed computing environment. That is, 
spaces may be structured as, for example, a flat un-related 
set of advertisements or a graph of related advertisements 
(e.g. commercial database). Since, in a preferred 
embodiment, the distributed computing environment does 
not dictate how a space actually stores its content, spaces 
may be supported by small to large devices. For example, a 
simple space may be tailored to fit on small devices, such as 
PDAs. More advanced spaces may be implemented on large 
severs employing large commercial databases. 

As mentioned above, a space may contain advertisements 
for services in the distributed computing environment. An 
advertisement may provide a mechanism for addressing and 
accessing services and/or content within the distributed 
computing environment. An advertisement may specify a 
URI for a service. In some embodiments, the URI may allow 
for the service to be accessible over the Internet. An adver- 
tisement may also include an XML schema for the service. 
The XML schema may specify a set of messages that clients 
of the service may send to the service to invoke functionality 
of the service. The XML schema may define the client- 
service interface. Together, the URI and the XML specified 
in an advertisement may indicate how to address and access 
the service. Both the URI and schema may be provided in 
XML as an advertisement in a space. Thus, a mechanism for 
addressing and accessing a service in a distributed comput- 
ing environment may be published as an advertisement in a 
space. Clients may discover a space and then lookup indi- 
vidual advertisement for services or content. 

FIG. 16 illustrates advertisement structure according to 
one embodiment. An advertisement 500, like other XML 
documents, may include a series of hierarchically arranged 
elements 502. Each element 502 may include its data or 
additional elements. An element may also have attributes 
504. Attributes may be name-value string pairs. Attributes 
may store meta-data, which may facilitate describing the 
data within the element. 

In some embodiments, an advertisement may exist in 
different distinct states. One such state may be a drafted 
state. In one embodiment, advertisements may initially be 
constructed in a drafted state that exists outside the bounds 
of a space. The creator of an advertisement may construct it 
in a variety of ways, including using an XML editor. Access 
to elements and attributes in the drafted state may be at the 
raw data and meta-data levels using any suitable means. 
Typically, events are not produced for changes made to 
advertisements in the drafted state. Therefore, the creator of 
the advertisement may be free to add, change, or delete 
elements as well as to achieve the desired attribute set, and 
then publish the advertisement for the rest of the distributed 
computing environment to see. 

In one embodiment, another possible state for advertise- 
ments is a published state. Advertisements may move to the 
published state when inserted into a space. Once the adver- 
tisement is in a space, interested clients, and services may 
locate it, e.g. using its name and/or its elements as search 
criteria. For example, search criteria may be specified as an 
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XML template document that may be compared (e.g. by the 
space service) with the advertisements in the space. Pub- 
lished advertisements may represent "on-line" services 
ready for clients to use. The message address (URI) of the 
service may be stored as an element in the advertisement. 
Advertisements that are removed from the space may tran- 
sition back to the drafted state where they may be discarded 
or held. Removal may generate an event so interested 
listeners may be made aware of the change. Message gates 
are typically created from published advertisements. 

In one embodiment, yet another possible state for adver- 
tisements is a persistent archived state. An archival proce- 
dure may turn a live published advertisement into a stream 
of bytes that may be persistently stored for later reconstruc- 
tion. Archived advertisements may be sent (e.g. in their raw 
XML form) from the space to an archival service. The URI 
for an advertisement's archival service may be stored as an 
element in the advertisement. XML may provide a format 
for storing and retrieving advertisements and representing 
the state of advertisement elements sufficient to reconstruct 
the advertisement objects). Advertisements may be stored 
in other formats as well, depending on archival service 
implementation. The process of making a published adver- 
tisement persistent may prepare the advertisement for the 
persistent archived state. Persistent advertisements may be 
stored (e.g. by an archival service) for future use in a 
persistent storage location such as a file or a database. A 
space through the archival procedure may enable advertise- 
ments to be stored, however the space does not necessarily 
play a role in how persisted advertisement entries are 
actually stored. How persisted advertisements are stored 
may be determined by the advertisement's archival service. 
Typically, no events are generated on behalf of archived 
advertisements. Also, changes may not be allowed for 
advertisements in the persistent archived state. 

Advertisements may be archived and removed or just 
archived. If an advertisement is archived without removing 
it from the space, the space will store a shadow version of 
the advertisement. Access to an archived service may cause 
the advertisement to "fault-in" from its persistent backing 
store on demand. This feature may allow advertisements to 
be filled, from LDAP (Lightweight Directory Access 
Protocol) entries for example, on demand, 

FIG. 17 illustrates one example of advertisement state 
transitions that an advertisement may undergo during its 
lifetime. First, an advertisement may be constructed, as 
indicated at 1. During construction, the advertisement is in 
the drafted state. Then, the advertisement may be inserted in 
a space, as indicted at 2. The advertisement may be inserted 
as a published parent. The advertisement is in the published 
state after being inserted in a space. An event (e.g. 
AdvInsertEvent) may be generated when the advertisement 
is inserted in the space. Events are more fully discussed 
below. The advertisement may be archived and made 
persistent, as indicated at 3, which may transition the 
advertisement to the persistent archived state. An advertise- 
ment may also be published from the persistent archive state, 
as indicated at 4. An advertisement may be removed from a 
space and transition back to the drafted state, as indicated at 
5. An event (e.g. AdvRemoveEvent) may be generated when 
the advertisement is removed. 

In one embodiment, the archived, persistent state is not 
used. In this embodiment, state changes 3 and 4 also are not 
used. In this embodiment, an advertisement is either in the 
drafted state or in the published state. 

Advertisements stored in a space may have the following 
standardized elements and/or attributes: version (may be an 
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element), creation date (may be an attribute), modification 
date (may be an attribute), implementation service URI (may 
be an element), and/or persistence archival service URI 
(may be an element). 

5 FIG. 48 is a flow diagram illustrating the addressing of a 
service using an advertisement stored in a space in a 
distributed computing environment according to one 
embodiment. In one embodiment, a service may publish a 
service advertisement in a space, as indicated at 2300. The 

10 space may be a network-addressable storage location which 
stores documents such as extensible Markup Language 
(XML) documents. The publishing of advertisements is 
described in greater detail elsewhere in this detailed descrip- 
tion. In one embodiment, the advertisement may include a 

15 Uniform Resource Identifier (URI) and a schema for the 
service. The URI may specify a network address at which 
the service may be accessed, and the schema may specify 
one or more messages which are usable to invoke one or 
more functions of the service. In one embodiment, the 

20 schema and the messages may be expressed in a data 
representation language such as XML. A client may access 
the space and find the advertisement, as indicated at 2302. 
For example, the client may use a discovery service to find 
the space and then a lookup service to find the advertisement 

25 within the space, such as illustrated by FIG. 47. 

In one embodiment, the advertisement includes substan- 
tially all the information needed by the client to access that 
particular service. The client may read the advertisement 
from the space, as indicated at 2304. In one embodiment, the 

30 client may use the URI and the schema in the advertisement 
to construct a gate for access to the service. As indicated at 
2305, the client may send a first message to the service at the 
URI, wherein the first message is specified in the schema, to 
invoke one or more functions of the service. In response, the 

35 function(s) of the service may be invoked, as indicated at 
2308. In one embodiment, the service may send a second 
message (e.g., a message including the results of the invoked 
function^)) to the client, wherein the second message is 
specified in the schema for the service. 

40 A space itself is typically a service. A space service may 
provide the ability to search for advertisements in the space, 
which may include searching the space by type of adver- 
tisements. A space service may also provide facilities to read 
advertisements, write (publish) advertisements, and take 

45 (remove) advertisements. A space may also provide the 
ability to subscribe for space event notification messages. 
Some spaces may provide extended facilities, such as facili- 
ties to navigate space relationship graph by position; read, 
write or take advertisement elements; read, write or take 

50 advertisement attributes; and subscribe for advertisement 
event notification messages. Space facilities are described in 
more detail below. A space's capabilities are embodied in a 
space advertisement's message schema. From the message 
schema, space address, and authentication credential, a 

55 client message gate may be created to access the space and 
its facilities. 

Spaces and all advertisements within a space may be 
addressed using URIs. In one embodiment, space and adver- 
tisement names may follow URL naming conventions. The 
60 use of URIs, e.g. URLs, for addressing spaces may allow 
spaces to be addressable throughout the Internet, in some 
embodiments. 

The space message recipient (a space service) may be 
specified using a URI which may have been received in a 
65 service advertisement for the space. The URI may include a 
protocol, host, port number, and name. The protocol may 
name the protocol that may be used to move messages 
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between clients and the space (reliable or un-reliable 
sockets, for example). The host and port number may be 
protocol dependent IDs. The name may be the space name 
followed by advertisement, element and/or attribute name. 
In one embodiment, a pathname may be used to identify an 5 
advertisement in a space. Pathnames may be either absolute 
or relative. Absolute pathnames name the space as well as an 
advertisement. Relative pathnames are relative a designated 
advertisement within an assumed space. In one embodiment, 
the syntax rules governing the construction of pathnames is 10 
that of the URI (Uniform Resource Identifier). In that 
embodiment, advertisement and space names therefore may 
not contain any URI reserved characters or sequences of 
characters. Pathnames to elements and attributes may also 
be specified using a URI. In general, element and attribute is 
names may be appended to the pathname of an 
advertisement, such as: 

http://java.sun.com/spacename/advertisement/element/ 
attribute. 

In one embodiment, the distributed computing environ- 20 
ment may include a mechanism that allows a client to 
discover the URI of a space but restricts access to the service 
advertisement for the space. In one embodiment, rather than 
returning the full advertisement to the space, the URI of the 
space and the URI of an authentication service for the space 25 
may be returned. In order for the client to access the 
documents or services advertised in the space, the client first 
may authenticate itself to the authentication service at the 
URI provided in the return message. The authentication 
service may then return an authentication credential that 30 
may allow the client partial or full access to the space. When 
the client receives the authentication credential, the client 
may attempt to connect to the space to access the documents 
or service advertisements in the space. 

The distributed computing environment may provide a 35 
mechanism or mechanisms that may enable a client to 
connect to a space. Embodiments of a connection mecha- 
nism may provide for client-space addressing, client 
authorization, security, leasing, client capabilities 
determination, and client-space connection management. A 40 
client-space connection may be referred to as a session. In 
one embodiment, a session may be assigned a unique session 
identification number (session ID). The session ID may 
uniquely identify a client-space connection. In one 
embodiment, a session lease mechanism may be used to 45 
transparently garbage collect the session if the client does 
not renew the lease. 

The following is an example of using such a connection 
mechanism according to one embodiment. A client may 
obtain an authentication credential. In one embodiment, the 50 
space may provide an authentication service in response to 
a client's request for access to the space. The client may 
obtain the authentication credential through the authentica- 
tion service. When the client receives the authentication 
credential, the client may initiate a connection to the space 55 
by sending a connection request message. In one 
embodiment, the connection request message may include 
the URI address of the space service, the authentication 
credential for the client and information about the connec- 
tion lease the client is requesting. After the space receives 60 
the connection request message, the space may validate the 
message. In one embodiment, an XML schema may be used 
to validate the message. The client may then be authenti- 
cated using the authentication credential. In one 
embodiment, the information received in the connection 65 
request message may be used to determine the capabilities of 
the client to use the space. In one embodiment, each client 
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of a space may be assigned its own set of capabilities for 
using the space. In one embodiment, an access control list 
(ACL) that may include capability information about one or 
more clients of the space may be used in client capabilities 
determination. In one embodiment, the information received 
in the connection request message may be used to look up 
the client's capabilities in the ACL. 

After authenticating the client and determining the cli- 
ent's capabilities, the connection lease to grant the client 
may be determined. After the lease is determined, the 
structure for maintaining the client-space connection may be 
generated. A session ID for the connection may be gener- 
ated. In one embodiment, each client-space connection may 
be assigned a unique session ID. In one embodiment, an 
activation space may be created and assigned to, or alter- 
natively a pre-existing activation space may be assigned to, 
the client-space session. In one embodiment, an activation 
space may be used to store results of services for the client 
when using the space. In one embodiment, a client's capa- 
bilities may be used to determine if an activation space is to 
be created for the client. For example, a client may not have 
capabilities to access an activation space to store and 
retrieve results. A message or messages may be sent to the 
client informing the client that the connection has been 
established. The message or messages may include the 
session ID and information about the lease. The client may 
then use the space including, but not limited to: advertise- 
ment lookup, advertisement registering, and advertisement 
retrieval. In one embodiment, he connection may remain 
open until the allocated lease expires or until the client sends 
a message requesting lease cancellation to the space. In one 
embodiment, the client may be responsible for renewing the 
lease before the lease expires. If the lease expires before the 
client renews the lease, the connection may be dropped, 
causing the client to lose the connection to the space. In one 
embodiment, to reconnect, the client may be required to 
repeat the connection procedure. 

In one embodiment, a client of a space may obtain a 
space's advertisement several different ways. Some of the 
ways a client may obtain a space's advertisement are illus- 
trated in FIG. 18. For example, a space discovery protocol 
may be provided as part of the distributed computing 
environment. Space discovery is a protocol a client or 
service may use to find a space. A listener agent 202 may be 
configured associated with one or more spaces to listen for 
discovery requests. The discovery listener agent 202 may 
listen on various network interfaces, and may receive either 
broadcast requests or unicast requests (at the URI of the 
agent) from clients 200a looking for a space(s). The listener 
agent 202 then responds with the service advertisement(s) or 
URIs for the service advertisements of the requested space 
(s). In one embodiment, the listener agent is, in general, 
separate from the space, because its functionality is orthogo- 
nal to the functionality of a space service. However, the 
listener agent may be implemented on the same device or a 
different device as a space service. 

In one embodiment, the discovery protocol may be a 
service advertised in a default space, A client may instantiate 
the discovery protocol from the client's default space in 
order to discover additional spaces. The discovery protocol 
may be pre-registered with a client's default space. 
Alternatively, the discovery protocol may register itself with 
the default space by placing an advertisement in that space, 
e.g., when a client connects to a local network serviced by 
the discovery service. 

In one embodiment, the space discovery protocol may be 
mapped to underlying device discovery protocols for other 
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platforms, such as SLP, Jini, UPnP, etc. Thus, a client may directly supported by these discovery protocols. To meet the 

use the discovery protocol of the distributed computing needs of such devices in discovering spaces in the distrib- 

environment to find services in other environments. Abridge uted computing environment, a pre-discovery protocol may 

to these other environments may be provided and advertise- used to find an IP network capable agent. The pre-discovery 

ments provided services in these other environments so that s protocol may include the device sending a message on a 

they may be accessed by clients of the distributed computing non .rp netW ork interface requesting a network agent. The 

environment described herein. Refer to the Bridging section. net work agent may set up a connection between itself and 

For each advertised discovery protocol, the distributed , he devlce 0nce lhe connection ^tween device ^ agent 

computing environment may create a subsequent results ^ se , , he , parlicipates jn the disc0V ery protocol on 

space to hold the results of the d^covery protocol. In one 1Q , p Qetworks on behalf of ^ device fof whicb ^ ^ 

embodiment, space services m the distributed computing Tfae Qetwork a|so ide M interface fof 

environment may use the Multicast Announcement Protocol , he deyice l0 , he distributed computing environment in 

(multicast UDP) to announce themselves on a LAN This , For ^ m bjJ conslrucled in the , 

information may be recorded by a ltstener agent. A device on beM[ of |h(J device for runnj servjces advertised in 

(either a client or service) may use the Multicast Request „ discovered s . See , he Brid m 

Protocol (multicast UDP) to initiate discovery of a space ^ way ^ clients may Iocate spaces m the distrib . 

manager. In one embodiment, the space managers respond med tin environment is by advertisement of a space 

with information indicating the URI of their respective in anomer A ce - a a xM M ljke Qlher 

spaces Alternatively a listener agent may respond for scrvicc> ., can b(J advertiscd in anolher spacc . M shown in 

multiple spaces. The discovery response may also include a 2fl F , G lg , ^ 2m find aQ adverliseraem 206 in a 

short string that labels the each space (e g. obtained from flRt 204(J fof , second e 2Mb s 204fe m 

keywords of the space), and information that can be used to fa turn indude advertisements t0 additioQa i spaces . Because 

set up a TCP connection, for example, with each space , servjce (implementing a space) may a iso act as a c i ient , 

manager to perform operations on the respective space. exch advertisemeDts or chain togelner t0 

Since the requesting device may receive responses from 2J prov ide a federation of spaces, as illustrated in FIG. 19. Any 

more than one space manager (or multiple space listings number of s be induded m , he distri5uted com . 

from a listener agent), this information may help the client . environment. The number and topology of spaces 

select which space it wishes to connect to. be implenientation depe ndent. For example, spaces 

In addition to the multicast thscovery described above, the on an IP netW ork might each correspond to a 

discovery service may also perform discovery using unicast 30 different subnet 

messaging (e.g. over TCP) that can be used to discover a A ^ a cUent ma locate a ^ m fa ^ 

space manager at a known address on the network (e.g. the a 208 M shown m nG lg Ascrvice 208 may be ^ 

Internet, other WAN, LAN, etc) The unicast discovery whjch retums B its rcsults the xr/ice advertisemenls of 

message may include a request for a space service at a M nkes. Since service advertisements are XML docu- 

known URI to provide its service advertisement. The mul- 3 , meQts and since the distributed computing environment may 

ticast and unicast discovery protocols are defined at the mdude me Internet> 208 may be a Web . based aBmh 

message level, and thus may be used regardless of whether tool ^ e h of such a ^ tbe , ook . 

the devices participating in the discovery support Java or xM(x described in ^^oa with F IG. 4. In one 

any other particular language. embodiment, spaces within the distributed computing envi- 

The discovery protocol may facilitate the proliferation of ^ ronment ma be implemented as Web pages . Each Web page 

clients independently of the proliferation of server content mdude a k rf , hat be searched , 0 

that supports those chents within the distributed computing idemif the Web M , in tbe dislributed comput . 

environment For example, a mobile chent may have its m environment . ^e space may include other searchable 

initial default space built into Us local platform. In addition keywords as wdl , 0 fonher define the space. A client may 

to local services advertised in the default space, the mobue 4J connect , 0 a search servjce 20g and , keywords to the 

client may have services that search for additional spaces, service M the form of XML messages . The search 

such as a service to access the discovery protocol or a may receive tbe keywords from the client and feed 

service to access space search engines. me keywords t0 an Internet search engine, which may be a 

In one embodiment, the distributed I computing environ- conventional or third-party search engine. The search ser- 

ment space discovery protocol may define a set of XML 5Q vice retum tbe results from lbe Internet search en ^ ne 

messages and their responses that may allow clients to: , 0 the cliem> eithef difectly as XML messages or by refer- 

Broadcast protocol-defined space discovery messages on e nce to a results space. The results may be the URls of 

their network interfaces. spaces matching the search request. Alternatively, the search 

Receive from listeners XML messages describing candi- service may contact spaces identified by the search, obtain 

date spaces that those listeners represent. 5S me service advertisement for each such space, and return the 

Select one of those discovered spaces as default, without space service advertisements to the client, either directly as 

the client needing to know tbe address of tbe selected XML messages or by reference to a results space. The client 

space. may then select a space from the search results and construct 

Obtain information on tbe selected space, such as its a gate (by itself or through a proxy) to access the selected 

address, so the client may later find that same space via 60 space. Once the selected space is accessed, the client may 

means outside of tbe discovery protocol (useful if later look up service advertisements within that space, which may 

the client wants to access a space whicb is no longer lead to additional spaces. 

local, but which still is of interest to the client). As described above, a space may be an XML-based 

In some embodiments, the multicast and unicast discov- Website, and as such may be searched via Internet Web 

ery protocols may require an IP network. Although these 65 search mechanisms. A space may include Internet searchable 

discovery protocols meet tbe needs of devices that are IP keywords. Some devices, such as small client devices, may 

network capable, there are many devices that may not be not support an internet browser. However, such devices may 
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still perform Internet searches for spaces within the distrib- 
uted computing environment. A device may have a program 
that accepts strings of keywords, which may be sent to a 
proxy program on a server (e.g. a search service). The proxy 
may send the strings to a browser-based search facility (e.g. 5 
an internet search facility) to perform the search. The proxy 
may receive the output of the search and parse it into strings 
(e.g. XML strings) representing each URI for the search 
results and send the response strings back to the client. Thus, 
a client may locate spaces through the Internet without ao 
having to support a program such as a Web browser. More 
capable devices may avoid the use of a proxy and initiate an 
Internet-based search service directly. 

FIG. 43 is a flow diagram illustrating a search for spaces 
using a search service in a distributed computing environ- 15 
ment according to one embodiment. In one embodiment, a 
client on a device may interact with a search service on the 
same or a different device to find spaces (i.e., network- 
accessible object repositories) for storage and/or retrieval of 
data. Embodiments of this interaction are further illustrated 20 
in FIGS. 46a and 46ft. The client 110 may send a search 
request to the search service 2102, as indicated at 2000. The 
search request may include one or more desired character- 
istics which are sought of a space. In one embodiment, the 
search request is expressed in a data representation language 25 
such as extensible Markup Language (XML). In one 
embodiment, the desired characteristics in the search request 
may include one or more keywords. The client may include 
a program 2100 that accepts the keywords and sends them 
to the search service 2102. In one embodiment, the key- 30 
words may be sent as XML messages 2106 and/or using 
gates are described herein. 

Based upon the search request, the search service 2102 
may conduct a search. In an embodiment shown in FIG. 46a, 
in conducting the search, the search service 2102 may 35 
interact with a search engine 2104 such as an Internet search 
engine. In this manner, the search service may act as a proxy 
between the client and the search engine. A proxy may be 
particularly desirable for a client on a small device which 
does not have the resources to interact with the search 40 
engine, such as by using a web browser or by receiving a full 
set of search results. The search engine may include a 
network-accessible third-party search engine, such as a 
browser-accessible Internet search engine. In an embodi- 
ment shown in FIG. 46b, the search service 2102 may 45 
include or otherwise be closely coupled to the search engine 
2104. The search service 2102 may translate the search 
request from the data representation language (e.g., XML) 
into a text format which is usable by the search engine 2104, 
as indicated at 2002. The search service 2102 may then send 50 
the translated search request to the search engine 2104, as 
indicated at 2004. 

As indicated at 2006, the search may be performed by the 
search engine 2104 to generate search results. The search 
results may include locations (e.g., URIs) of one or more 55 
resulting spaces such as 2120a, 2120ft, and 2120c, for 
example. In one embodiment, the spaces may include one or 
more web pages which are accessible over the Internet 2110. 
The web pages may include an identifying keyword which 
identifies the web pages as spaces within the distributed 60 
computing environment. The search request may include 
this keyword along with one or more other keywords which 
describe the characteristics which are desired of the spaces. 

As indicated at 2008, the search service 2102 may receive 
the search results in the text format from the search engine 65 
2104. The search service 2102 may then translate the search 
results in the text format into search results in the data 
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representation language (e.g., XML) and send the results to 
the client 110, as indicated at 2010. In one embodiment, the 
search service 2102 may obtain a service advertisement for 
each of the resulting spaces 2120a, 2120ft, and 2120c. Each 
service advertisement includes information which is usable 
to access the respective space. The search service 2102 may 
send references (e.g., Uniform Resource Identifiers) to these 
advertisements or the advertisements themselves as the 
search results to enable the client to access the resulting 
spaces at their respective locations, as indicated at 2012. In 
one embodiment, the locations of the resulting spaces 
include Uniform Resource Identifiers (URIs). 

In one embodiment, in sending the search results to the 
client 110, the search service 2102 may store the search 
results in a results space (i.e., a network-accessible storage 
repository) and send the address of the results space to the 
client 110. The client 110 may then access the search results 
in the results space at an appropriate time. The use of a 
results space may be especially desirable for a small client 
that does not possess the resources to receive and display a 
full set of results. In this situation, the user may read the 
results from the results space using a different client accord- 
ing to one embodiment. 

In some embodiments, a search service may limit or filter 
spaces that may be found through the search service, or 
constrain clients to searching only a few supported spaces 
within the distributed computing environment. The extent of 
searching permitted may be determined according to the 
client authentication. 

A fourth way a client may locate a space is by obtaining 
or receiving information about a newly created empty space 
or a spawned space when an existing space is spawned. An 
existing space may include an interface for spawning an 
empty space with the same functionality (e.g. same XML 
schema) as the space from which it is spawned. Spawning of 
spaces is further described below. 

Once a client of a space finds the advertisement of a space 
service, that client of the space may run the space service, as 
it would any other service. Note that the client of the space 
service may be another service (e.g. a service seeking to 
advertise in the space). In one embodiment, as illustrated in 
FIG. 20, to run a space service, the client of the space may 
first run an authentication service for the space to obtain an 
authentication credential, as indicated at 300. The authenti- 
cation service may be specified in the service advertisement 
of the space service. The client of the space uses the 
authentication credential, the XML schema of the space 
(from space's service advertisement), and the URI of the 
space (from space's service advertisement) to construct a 
gate for the space, as indicated at 302. The client of the space 
may then run the space service by using the gate to send 
messages to the space service. A first such message is 
indicated at 304. 

For embodiments employing authentication, when the 
space service receives the first message from the client, with 
the authentication credential embedded, the space service 
uses the same authentication service (specified in the service 
advertisement of the space service) to authenticate the client, 
thus establishing its identity, as indicated at 306. The space 
service may determine the client's capabilities and bind 
them to the authentication credential, as indicated at 308. 

As indicated at 310, a client of a space may run various 
space facilities by sending messages to the space service. In 
one embodiment, when a client of a space sends a request to 
the space service, it passes its authentication credential in 
that request, so the space service can check the request 
against the client's specific capabilities. 
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Each space is typically a service and may have an XML stands for Atomicity, Consistency, Isolation, and Durability, 
schema defining the core functionality of the space service. Atomicity means that a transaction should be done or 
The XML schema may specify the client interface to the undone completely. In the event of a failure, all operations 
space service. In one embodiment, all space services may and procedures should be undone, and all data should 
provide a base-level of space-related messages. The base- 5 rollback to its previous state. Consistency means that a 
level space functionality may be the basic space function- transaction should transform a system from one consistent 
ality that is capable of being used by most clients, including state to another consistent state. Isolation means that each 
small devices such as PDAs. It may be desirable to provide transaction should happen independently of other transac- 
tor additional functionality, e.g. for more advanced clients. tions occurring at the same time. Durability means that 
Extensions to the base-level space may be accomplished by 10 completed transactions should remain permanent, e.g. even 
adding more messages to the XML schema that advertises during system failure. Other transaction models may also be 
the space. For example, in one embodiment, the base-level specified in extended space schemas. 
messages do not impose any relationship graph upon the Extended space schemas may be XML documents that 
advertisements. Messages, for example, to traverse a hier- specify the message interface (e.g. XML messages) for using 
archy of advertisements may be a space extension. Provid- 15 extended space features, functionality or facilities. A space 
ing such additional functionality may be done by providing may have a base schema and multiple extended schema, 
one or more extended XML space schemas or schema This may facilitate provided different levels of service to 
extensions for a space. The extended schemas may include different clients depending upon the client authentication, 
the base schema so that clients of an extended space may Besides extensions for space persistence, structure, and 
still access the space as a base space. 20 transactions, other space extensions may also be specified as 

In one embodiment, a base space service may provide a desired. For example, extensions may be provided to 

transient repository of XML documents (e.g. advertisements manipulate advertisements at the element or attribute level: 

of services, results of running services). However, a base read, write or take advertisement elements; read, write or 

space service in one embodiment may not provide for take advertisement attributes; and subscribe for advertise - 

•advanced facilities to support persistence of space content, 25 ment event notification messages. A space may provide 

navigation or creation of space structure (e.g. hierarchy), and virtually any number of facilities and arrange them in base 

a transactional model. A mechanism for supporting and extended schemas as desired. In one embodiment, all 

persistence, hierarchy, and/or transactions is by extending base spaces must provide for advertisement reading, writing, 

the XML schema. Since extended spaces still include the taking, and lookup facilities, and space event subscriptions, 

base XML schema, clients may still treat extended spaces as 30 Various space facilities may be provided. In some 

base spaces, when just the base space functionality is all that embodiments, a facility may be provided for the establish- 

is need or all that can be supported. ment of a session with the space. In one such embodiment, 

In one embodiment, the base space may be transient. The the rest of the space functionality is not available until this 

base space may be acceptable for many purposes. Service is done. In other embodiments, the notion of a session is not 

providers may register their services in various spaces. In 35 provided for, or is optional and/or implementation depen- 

one embodiment, services must continuously renew leases dent. 

on the publishing of information in the spaces. By this Another space facility may be to add or remove a service 

nature, the services advertisements may be transient in that advertisement to or from the space. A space facility may also 

they may often be rebuilt and/or reconfirmed. However, it be provided for adding or removing an XML document (not 

may be desirable to provide for some persistence in a space. 40 an advertisement, but perhaps a result in a space). The space 

For example, a space that has results may provide some service may check for uniqueness of an item before aUowing 

persistence for users that want to be sure that results are not the addition of the item. For example, each item added to the 

lost for some time. In one embodiment, persistence may be space may be associated with a user-specified string that 

provided for by specifying a space interface where the client identifies the item and that may be used to check for the 

may control which objects in the space are backed by a 45 uniqueness of the item. 

persistent store and manage the maintenance of that persis- In one embodiment, a client may request a listing, tree, or 

tence store. The persistence interface may be specified with other representation of all services advertised in the space, 

extended XML schema for the space defining the interfaces The user may then scroll or maneuver through the adver- 

for persistence. tisements and select the desired service. A space may also 

In one embodiment, a base space may provide an interface 50 provide a look-up facility that allows a client to search for 

where an XML document may be added to a space and a service by providing keywords or string names. In one 

identified by a string. The base space may not provide any embodiment, a space facility may provide a mechanism to 

hierarchy for the various so named XML documents in the look up a space entry that has been added to the space. The 

space. In embodiments where hierarchy support is desired, look up facility may search by string to match for name, or 

additional interfaces may be defined (extending the XML 55 wildcard, or even database query. The look up facility may 

schema) where a hierarchy can be specified by the user. return multiple entries from which the client may select one 

Other interfaces may be specified to navigate the hierarchy or perform a further narrowing search. In one embodiment, 

or navigate a relationship graph by position. However, other the look-up facility may provide a mechanism to locate a 

users may still use the base space interfaces to access those service advertisement matching a particular XML schema, 

same documents, without any hierarchy. Interfaces for other 60 The client may indicate a particular XML schema, or part of 

space structure may be provided for as well in extended a particular XML, to be searched for within the space. Thus, 

space schemas. a service may be searched for within a space according to its 

Extended XML space interfaces may also be provided for interface functionality, 

space transaction models. For example, an extended space FIG. 47 is a flow diagram illustrating a search for docu- 

XML schema may be provided specifying an interface for 65 ments within a space in a distributed computing environ- 

ACID transactions. ACID is an acronym used to describe ment according to one embodiment. In one embodiment, a 

four properties of an enterprise-level transaction. ACID client may interact with a space via lookup messages to find 
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documents within the space. A client may send a lookup 
message to a space, as indicated at 2200. The space may 
comprise a network-addressable storage location which is 
operable to store one or more documents. The stored docu- 
ments may be expressed in a data representation language 
such as extensible Markup Language (XML). The lookup 
message may specify desired characteristics of the stored 
documents. In one embodiment, the documents may include 
XML service advertisements and XML device advertise- 
ments as well as general-purpose XML documents. For 
example, the XML documents in the space may include the 
results of a service as expressed in XML. 

A set of documents which match the lookup message may 
be discovered, as indicated at 2202. The discovered docu- 
ments may include any stored documents which meet the 
desired characteristics specified in the lookup message. Zero 
or more stored documents may match the desired charac- 
teristics. In one embodiment, the lookup message may 
include a desired name. In one embodiment, the desired 
name specified in the lookup message may include one or 
more wildcards. Each of the discovered documents may then 
have a name that matches the desired name, and the names 
may identify the discovered documents within the space. In 
one embodiment, the lookup message may include a desired 
schema which is expressed in the data representation lan- 
guage. Each of the discovered documents may have a 
schema or part of a schema that matches the desired schema. 
In one embodiment, the lookup message may include both 
a desired name and a desired schema. In this case, the set of 
discovered documents may include both discovered docu- 
ments having a name that matches the desired name and 
discovered documents having a schema that matches the 
desired schema. In one embodiment, the lookup message 
may include neither a desired name nor a desired schema. In 
this case, the lookup message is essentially a request for all 
documents in the space, and the set of discovered documents 
may include substantially all the documents that are stored 
in the space. 

After the matching documents are found, the space may 
send a lookup response message to the client, as indicated at 
2204. In one embodiment, the lookup response message may 
include the names of the discovered documents. In one 
embodiment, the lookup response message may include an 
advertisement for each of the zero or more discovered 
documents. Each advertisement may include information 
which is usable by the client to obtain the respective 
discovered document or access the resource (e.g., a service) 
that the document advertises. In one embodiment, each 
advertisement may include a Uniform Resource Identifier 
(URI) at which the respective discovered document (or 
resource, such as a service, advertised by the document) is 
accessible. In one embodiment, at least one of the discov- 
ered documents may be an advertisement for a service. The 
advertisement for the service may include a schema, wherein 
the schema specifies one or more messages usable to invoke 
one or more functions of the service. The advertisements 
may be expressed in the data representation language, such 
as XML. 

In one embodiment, the lookup message and the lookup 
response message are expressed in a data representation 
language such as XML. A schema for the space may specify 
the form of the lookup message and lookup response mes- 
sage. In one embodiment, this pair of messages may be 
expressed in XML as follows. 
Lookup Message 

<Space> 

<LookupAdvertisement> 
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<AdvertisementName>Name</AdvertisementName> 
<AdvertisementSchema>AdvSchema</Adverti 
sementSchema> 
</LookupAdvertisement> 
</Space> 
Lookup Response Message 
<Space> 

<LookupAdvertisementResponse> 

<Advertisement>Adv</Advertisement> 
<AdvertisementName>Names</AdvertisementName> 

</LookupAdvertisementResponse> 

</Space> 

In the XML lookup message, Name may be string-valued 
and may specify a unique identifier within the space. If a 
wildcard is used, then the identifier may not be unique. 
AdvSchema is a schema which the lookup is expected to 
match. In one embodiment, both fields are optional. In the 
XML lookup response message, Adv is a group of zero or 
more matching advertisements, and Names is a group of 
names corresponding to the advertisements. 

Another space facility that may be provided in the dis- 
tributed computing environment is a mechanism that allows 
services and clients to find transient documents based upon 
a typing model such as XML. The mechanism may be a 
general-purpose, typed document lookup mechanism. In one 
embodiment, the lookup mechanism may be based upon 
XML. The lookup mechanism may allow clients and ser- 
vices to find documents in general, including services ~ 
through service advertisements. 

In one embodiment, a space lookup and response message 
pair may be used to allow clients and services to find XML 
documents stored within a network transient document store 
(space). The space may be a document space used to store 
a variety of documents. In one embodiment, the documents 
are XML documents or non-XML documents encapsulated 
in XML. Spaces are further described elsewhere herein. The 
lookup messages may work on any kind of XML document 
stored in the space, including service advertisements and 
device driver advertisements. In one embodiment, a client 
(which may be another service) may use a discovery mecha- 
nism as described elsewhere to find one or more document 
spaces. Then, the client may use space lookup messages to 
locate documents stored in the space. 

The distributed computing environment may include a 
mechanism that allows services and clients to subscribe to 
and receive events about the publication of XML docu- 
ments. Events may include the publication of and removal of 
XML documents to and from a transient XML document 
repository such as a space. In one embodiment, an event may 
be an XML document that refers to another XML document. 

In one embodiment, a space event subscription and 
response message pair may be used to allow clients and 
services to subscribe for events regarding documents that are 
added to or removed from a space. In one embodiment, an 
event subscription may be leased using the leasing mecha- 
nisms described elsewhere herein. In one embodiment, a 
subscription may be cancelled when the lease is cancelled or 
expires. In one embodiment, a subscription may be renewed 
by renewing the lease to the subscription. 

In one embodiment, an event subscription message may 
include an XML schema that may be used as a document 
matching mechanism. Documents that match the schema 
may be covered by the subscription. In one embodiment, any 
document added to a space and that matches the XML 
schema may generate a space event message. 

A space facility may also be provided to which a client 
may register (or unregister) to obtain notification when 
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something is added to or removed from the space. A space 
may contain transient content, reflecting services that at 
added and removed from the space. A mechanism may be 
provided to notify a client when a service becomes available 
or becomes unavailable, for example. A client may register 
with an event service to obtain such notification. In one 
embodiment, a client may register to be notified when a 
service having a name matching a specified string or a 
schema matching a specified schema (or schema portion) is 
added or deleted from the space. Thus, a query to register 
with the space event notification facility may be the same as 
or similar to that of the service look up facility described 
above. 

When a client of a space subscribes to be notified when an 
XML documents) (e.g. service advertisement) is added or 
removed from the space, the client may obtain a lease on this 
subscription to notifications. The lease may allow the space 
service to know whether to continue sending notifications to 
a particular client. For example, a lease to the notification 
facility may expire after an amount of time if not renewed. 
Note that a lease may not be required while a client has 
established an active session with a space. Once, a client has 
discontinued an active session with a space, it may continue 
to receive event notifications according to its event subscrip- 
tions as long as its corresponding leases remain active. Refer 
to the Leases section below. 

A client may subscribe to different types of events. 
Examples are a service advertisement being added or 
removed from a space, as described above. A client may also 
be notified when results from a service initiated by the client 
(or by someone else) are put in a space. For example, the 
client and the service may mutually select a name for 
referring to the results of the service. The client may register 
with the space service to which the results are to be posted 
or advertised to receive an event when a result referenced by 
the selected name is added to the space. 

A space may generate different types of events to which 
a client may subscribe. As the composition of a space 
changes, events may be produced to those clients and 
services that have subscribed for such events. In one 
embodiment, there may be two major space event 
categories, those that pertain to the space (insertion and 
removal of advertisements), and those used that indicate 
changes to an advertisement (adding, removing, changing an 
element or attribute). Which events are supported may be 
indicated in the XML message schema for the space. 

The following events are examples of events that may be 
produced by a space service to indicate an space or adver- 
tisement event: 

TABLE 1 



Space Events 



Event Name 



Type 



Meaning 



Advertisement 
Insertion Event 

Advertisement 
Removal Event 

Advertisement 
Element Insertion 
Event 

Advertisement 
Element Removal 
Event 



AdvInsertEvent 



AdvRcmovcEvcnt 



AdvElement[nsertEvent 



AdvEiementRc mo ve Event 



New advertisement 
has been inserted into 
a space 

Existing advertisement 
has been removed 
from a space 
A new element has 
been added to an 
advertisement 
Existing element has 
been removed from an 
advertisement 
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TABLE 1 -continued 



Space Events 



Event Name 



Type 



Meaning 



Advertisement 
Element Change 
Event 

Advertisement 

Element 

Attribute 

Insertion Event 

Advertisement 

Element 

Attribute 

Removal Event 

Advertisement 

Element 

Attribute 

Change Event 



AdvEle me ntCha nge Event 



Adv Ele me ntAttribute I nsert 
Event 



AdvEleme n tAttribute Re move 
Event 



Adv Ele me n tAttribute Change 
Event 



Existing element has 

been changed in an 

advertisement 

A new attribute has 

been added to an 

element 

Existing attribute has 
been removed from an 
element 

Existing attribute has 
been changed in an 
element 



Events may be typed. In some embodiments, the event 
facilities supported by spaces may allow for event listeners 
to take advantage of, e.g., Java class (or XML types) 
hierarchies. For example, by listening for 
AdvElementEvent, the listener will receive events of type 
AdvElementEvent and all of its sub-classes (XML types). 
Thus, for this example all events pertaining to element 
changes (though not advertisement insertion and removal) 
are received. 

By way of further example, subscribing to or listening for 
a top-level event class or type, e.g. SpaceEvent, will result 
in the reception of all space events. Event class types may 
be distinguished via, for example, the Java instance of 
operator or the XML typing system. 

An event may include a URI to the affected advertisement 
or element. For example, AdvertisementEvent and all its 
sub-classes may contain a reference (e.g. URI or URL) to the 
affected advertisement. AdvElementEvent and its subclasses 
may be examined for the name of the affected element. The 
previous element value (URI or URL), may be available, for 
example, from AdvElementRemoveEvent and AdvEle- 
mentValueChangeEvent. 

A space event type hierarchy for one embodiment is 
illustrated in FIG. 21. Types may be defined in XML and 
usable in Java or any other suitable object-oriented language 
such as C+4*. 

A space may provide a facility for a client to instantiate a 
service advertised in the space. Service instantiation is the 
initialization done that allows a client to be able to run a 
service. On embodiment of service instantiation is illustrated 
in FIG. 22. To instantiate a service, a client may first select 
one of the service advertisements published in the space, as 
indicated at 320. The client may use the various facilities, 
such as the look up facility, provided by the space to look up 
the various advertisements in the space. Then the client may 
request the space to instantiate the service, as indicated at 
322. 

In one embodiment, service instantiation may include the 
following actions. After the client requests the space service 
to instantiate the selected service, as indicated at 322, the 
space service may then verify the client is allowed to 
instantiate the requested service, as indicated at 324. The 
space service may perform this verification by examining an 
authentication credential included in the clients message. 
The authentication credential is the credential the client 
received when it established a session with the space service. 
The space service may verify if the client is allowed to 
instantiate the requested service according to the client's 
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authentication credential and capabilities indicated for that it may be discovered just like other spaces using one or more 

client. See the Authentication and Security section herein. of the space discovery mechanisms described herein. 

Assuming the client is authorized, the space service may FIG. 41 is a flow diagram illustrating the spawning of a 

also obtain a lease on the service advertisement for the client new space in a distributed computing environment accord- 

with the lease request time specified by the client, as 5 ing to one embodiment. As indicated at 1900, a client may 

indicated at 326. Leases are further discussed below. The access (i.e., connect to) a first space service. (A service may 

space service may then send a message to the client which act as a client for the purpose of accessing or otherwise using 

includes the allocated lease and the service advertisement of a space.) The first space service may store one or more 

the service, as indicated at 328. In one embodiment, the service advertisements and/or other content in a first space, 

client may run an authentication service specified in the 10 and each of the service advertisements may include infor- 

service advertisement and obtain an authentication mation which is usable to access and execute a correspond- 

credential, as indicated at 330. See the Authentication and ing service. The first space service may include a first 

Security section herein for more information on an authen- schema which specifies one or more messages usable to 

tication service. Next, as indicated at 332, the client may invoke functions of the first space service. For example, the 

construct a gate for the service (for example, using the is first schema may specify methods for reading advertise - 

authentication credential and the XML schema and service ments from the first space and publishing advertisements in 

URI from the advertisement). Refer to the Gates section the first space. The first schema and service advertisements 

herein. The above described communication between the may be expressed in an object representation language such 

client and space service is performed using the XML mes- as extensible Markup Language (XML). In accessing the 

saging of the distributed computing environment. The client 20 first space service, the client may send information such as 

may then run the service using the constructed gate and an XML message (as specified in the first schema) to the first 

XML messaging. The service may similarly construct a space service at a first Internet address (e.g., URI), In 

service gate for XML message communication with the accessing the first space service, the client may search the 

client. one or more service advertisements stored in the first space. 

To summarize, an example use of a space is discussed as 25 In one embodiment, spaces may include a facility for 

follows. A client may access (e.g., connect to) a space spawning new spaces. As indicated at 1902, the creation of 

service. (A service may act as a client for the purpose of a second space may be requested, such as by the client 

accessing or otherwise using a space.) The space service sending an appropriate request to an interface of the first 

may store one or more service advertisements and/or other space. In one embodiment, the request may be formatted as 

content in a space, and each of the service advertisements 30 an XML message according to the first schema for the first 

may include information which is usable to access and space. In response, a second space service with a second 

execute a corresponding service. The space service may space may be created, such as at a second Internet address 

include a schema which specifies one or more messages (e.g., URI), as indicated at 1904. As above, the second space 

usable to invoke functions of the space service. For example, service may include a second schema which specifies one or 

the schema may specify methods for reading advertisements 35 more messages usable to invoke functions of the second 

from the space and publishing advertisements in the space. space service. The second schema may include at least the 

The schema and service advertisements may be expressed in first schema, and the second schema may include additional 

an object representation language such as extensible functionality as well. In one embodiment, the schema of the 

Markup Language (XML). In accessing the space service, second space may include a portion of the first schema, or 

the client may send information such as an XML message 40 the second schema may be specified at the lime of creation 

(as specified in the schema) to the space service at an of the second space. As indicated at 1906, the client may 

Internet address. In accessing the space service, the client then access the second space by sending to the second space 

may search the one or more service advertisements stored in at least one of the messages specified in the second schema, 

the space. The client may select one of the service adver- Spawning a space may include administration 

tisements from the space. In one embodiment, the client may 45 initialization, such as for security. In one embodiment, when 

send an instantiation request to the space after selecting the a requestor has just spawned a space, only the requestor is 

desired service advertisements from the space. A lease may initially allowed to access the spawned space. Such limiting 

be obtained for the desired service, and the lease and the of access to the spawned space may be useful when a client 

selected service advertisement may be sent by the space and service are using that spawned space to store results, 

service to the client. The client may then construct a gate for 50 Refer to the Authentication and Security section for more 

access to the desired service. The desired service may be information on spawned space authentication and security, 

executed on behalf of the client. Once a client has spawned a new space, it may build a gate 

Another facility provided by a space service may be the to access the spawned space, 

spawning or creation of an empty space. This space facility By using a mechanism in which a space may be created 

may allow a client (which may be a service to another client) 55 via an interface in another space (e.g. a space spawning 

to dynamically create a new space. In one embodiment, this facility), new spaces may be created efficiently. For 

space facility may include an interface for spawning an example, in one embodiment, storage for the spawned space 

empty space with the same functionality (same XML may be allocated using the same facility used by the original 

schema or extended schema) as the space from which it is space for storage. In one embodiment, the first space may 

spawned. This facility may be useful for generating (e.g. 60 store a first set of information, such as XML advertisements 

dynamically) spaces for results. For example, a client may or other content, according to a particular storage model, 

spawn a space a request a service to place results or advertise Upon its creation, the second space is operable to store a 

results in the spawned space. The client may pass the second set of information according to the same storage 

spawned space URI and/or authentication credential to the model. Also, a spawned space may share a common service 

service. Or a service may spawn a space for results and pass 65 facility with its original (or parent) space. For example, a 

the spawned space URI and/or authentication credential to new URI may be assigned to the new space. In one 

the client. In some embodiments, once a space is spawned, embodiment, the new URI may be a redirection to a com- 
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mon space facility shared with the original space. Thus, a 
newly spawned space may use the same or some of the same 
service code as that of the original space. In other words, the 
first space service may include a set of program instructions 
which are computer-executable to provide the first space. 5 
The second space service may include substantially the same 
set of program instructions, wherein the set of program 
instructions are further computer-executable to provide the 
second space. 

Space facilities may also include security administration, 10 
for example, to update the various security policies of the 
space, and other administrative facilities. For example, the 
number and age of advertisements may be controlled and 
monitored by a root space service. Old advertisements may 
be collected and disposed. See, e.g., the Leases section 35 
herein for when an advertisement may be considered old. 
The service implementing the space may be under the 
control of an administrator. The administrator may set policy 
in a service dependent manner. 

Space facilities may also include a facility to delete an 20 
empty space. 

Certain spaces may include facilities or services to further 
support the proliferation of certain clients, such as mobile 
clients. For example, services in spaces that a mobile client 
may discover, e.g. via the discovery protocol, may provide 2 $ 
support for mobile clients, such as: 

Assigning and administering temporary network 

addresses for the client. 
Proxying message passing for the client. 
Providing search facilities for additional spaces. For 30 
example, a service may allow a client to specify key- 
words through a simple interface. The service then uses 
the keywords in conjunction with Web search engines 
to search for spaces on the Web, as further described 
herein. In other embodiments, a search service may 35 
constrain clients to searching only a few supported 
spaces within the distributed computing environment. 
As mentioned earlier (see FIG. 9 and accompanying text), 
spaces may provide a convenient mechanism for storing 
results from a service run by a client. Using a space for 40 
results may allow a small client to receive in pieces the 
results of running a service. Some services may generate a 
large amount of results. By using a space to store the results 
from a service, clients that do not have the resources to 
receive the full results at once may still use the service. 45 
Moreover, by using a space to store results, a service running 
on a fast busy server may be freed from interacting directly 
with a slow client when returning large results. Thus, the 
service may be freed sooner for use by other clients. 

A space may provide a convenient mechanism for access- 50 
ing a result by different clients and/or at different times. For 
example, a client may not be able to use the entire result, but 
a user may want to access the rest of the result later using 
another client that can access it. For example, the result 
could be stock quote information, showing the current price 55 
of a stock (accessible by a PDA), and showing a chart of 
stock prices (accessible by a laptop later). Also, using a 
space in the distributed computing environment for results 
may allow a client to feed the result of one service into 
another service, without the necessity of downloading the 60 
result first. For example, in the case of the stock quote 
information above, the PDA could feed the chart into 
another service, which prints the chart, without the PDA 
having to download the chart itself. Thus, a results space 
may provide a mechanism for a client to pass to another 65 
client or service without the client having to handle or 
receive the results. 
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In different embodiments, the decision to use a space for 
results may be mandated by the service, mandated by the 
client, and/or requested by tie client. A service may suggest 
the use of a space for its results, e.g., in its advertisement. In 
one embodiment, either the client or the service may spawn 
a new space for results or use an existing space for results. 
See the description herein regarding spawning spaces. 

In one embodiment, the use of a space for results does not 
necessarily mean that the service must put all results in that 
space. There may be alternatives for any result a service 
generates. For example, part or all of the result may be sent 
in-line in a message to the client. Alternatively, the result 
may be put in the space, and then a notification message may 
be sent to client, referencing the result (e.g. including a URI 
to the result or to an advertisement for the result). Another 
option may be to put the result in the space, with notification 
via an event from the space. For example, the client and the 
service may agree to call the result some particular name, 
and then the client may register with the space (using a space 
facility such as described above) to receive an event when a 
result so named is added to the space. See the description 
above on event notification. 

Thus, several different mechanisms may be employed 
within the distributed computing environment for a service 
to return results to a client. The actual results may be 
returned to the client by value in an XML message, or results 
may be returned to the client by reference with the actual 
results (or advertisement for the actual results) put in a space 
and the client receiving a message referencing the results in 
the space. Moreover, results, or results advertisements, may 
be placed in a space and the client notified by event. 

In various embodiments, therefore, results may be 
returned to a client in a plurality of ways: for example, in a 
message, in a space, in a space wherein the client is notified 
via an event, using an advertisement returned in a message, 
using an advertisement returned in a space, and using an 
advertisement returned in a space wherein the client is 
notified via an event. These various methods of returning 
results are illustrated in FIGS. 44a through 44g. The avail- 
ability of these plurality of methods may enhance the 
flexibility and adaptability of the distributed computing 
environment for a variety of situations, such as for clients 
having differing capabilities. For additional flexibility, 
results may also be efficiently passed to another service, as 
illustrated in FIG. 45. 

FIG. 44a is a flow diagram illustrating a method of storing 
result of a service in a space in a distributed computing 
environment according to one embodiment. As indicated at 
2050, a client may send a first message to a service to request 
invocation of one or more functions of the service. A schema 
for the service may specify a plurality of messages, includ- 
ing the first message, which are usable to invoke the 
functions) of the service. The messages and the schema 
may be expressed in a platform-independent and/or 
programming-language-independent data representation 
language such as XML. 

In response to the first message, the function(s) of the 
service may be invoked, as indicated at 2052. The service 
may then generate a set of results, as indicated at 2054. The 
results may be expressed in the data representation language 
(e.g., XML), As indicated at 2056, the service may store the 
set of results at a location in a space, wherein the space 
comprises a network-addressable storage location. In one 
embodiment, the space may be created in preparation for 
storing the set of results. 

As indicated at 2058, a client may then access and read the 
set of results from the space. In one embodiment, a second 
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client (i.e., a different client than tbe one that sent the 
message to invoke the function(s)) may read the set of 
results from the space. In this manner, a user may utilize a 
second client to read and display results when the first client 
may not have sufficient resources to accomplish such a task. 5 
In one embodiment, the client may send a message to the 
service to request that tbe service pass the address of the set 
of results to a second service, so that the second service may 
read the set of results from the address in the space. The 
second message may include a Uniform Resource Identifier 10 
(URI) of an advertisement for the second service, wherein 
the advertisement for the second service comprises infor- 
mation which is usable to access the second service. In this 
manner, tbe results may be efficiently passed from the first 
service to the second service without being passed to the is 
client. 

FIG. 44b is a flow diagram illustrating a method of storing 
results of a service in a space and notifying a client using an 
event according to one embodiment. As indicated at 2050, a 
client may send a first message to a service to request 20 
invocation of one or more functions of the service. In 
response to the first message, the function(s) of the service 
may be invoked, as indicated at 2052. The service may then 
generate a set of results, as indicated at 2054. The results 
may be expressed in the data representation language (e.g., 25 
XML). As indicated at 2056, the service may store the set of 
results at a location in a space, wherein the space comprises 
a network-addressable storage location. As indicated at 
2057, an event may be generated and sent to the client to 
notify the client that the results are stored in the space. As 30 
indicated at 2058, a client may then access and read the set 
of results from the space in response to the event. 

FIG. 44c is a flow diagram illustrating a method of 
sending results of a service in a message to a client accord- 
ing to one embodiment. As indicated at 2050, a client may 35 
send a first message to a service to request invocation of one 
or more functions of the service. In response to the first 
message, the functions) of the service may be invoked, as 
indicated at 2052. Trie service may then generate a set of 
results, as indicated at 2054. The results may be expressed 40 
in the data representation language (e.g., XML). As indi- 
cated at 2055, the service may then send to the client a 
message including the results. The message may be 
expressed in the data representation language (e.g., XML) 
and, in one embodiment, may be specified in the schema for 45 
the service. 

FIG. 44d is a flow diagram illustrating a method of 
returning results of a service using an advertisement accord- 
ing to one embodiment. As indicated at 2050, a client may 
send a first message to a service to request invocation of one 50 
or more functions of the service. In response to the first 
message, the function(s) of the service may be invoked, as 
indicated at 2052. The service may then generate a set of 
results, as indicated at 2054. The results may be expressed 
in the data representation language (e.g., XML). In one 55 
embodiment, the service may store the set of results at a 
location in a space, wherein the space comprises a network- 
addressable storage location. As indicated at 2060, the 
service may generate an advertisement for the results. The 
advertisement may include information which is usable to 60 
access and read the results, such as from the space. For 
example, the advertisement may include a Uniform 
Resource Identifier (URI) at which the results may be 
accessed. In one embodiment, the advertisement may 
include a schema (e.g., an XML schema) which specifies a 65 
format of the results. In one embodiment, the advertisement 
may be expressed in a data representation language such as 
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XML. As indicated at 2068, a client may then access and 
read the set of results using the advertisement. In one 
embodiment, a second client (i.e., a different client than the 
one that sent the message to invoke the function(s)) may 
read the results using the advertisement. 

FIG. 44e is a flow diagram illustrating a method of 
returning results of a service using an advertisement sent to 
a client in a message according to one embodiment. As 
indicated at 2050, a client may send a first message to a 
service to request invocation of one or more functions of the 
service. In response to the first message, the function(s) of 
the service may be invoked, as indicated at 2052. The 
service may then generate a set of results, as indicated at 
2054. The results may be expressed in the data representa- 
tion language (e.g., XML). In one embodiment, the service 
may store the set of results at a location in a space, wherein 
the space comprises a network-addressable storage location. 
As indicated at 2060, the service may generate an adver- 
tisement for the results. The advertisement may include 
information which is usable to access and read the results, 
such as from the space. For example, the advertisement may 
include a Uniform Resource Identifier (URI) at which the 
results may be accessed. In one embodiment, the advertise- 
ment may include a schema (e.g., an XML schema) which 
specifies a format of the results. In one embodiment, the 
advertisement may be expressed in a data representation 
language such as XML. As indicated at 2061, the service 
may send a message including the advertisement to the 
client. The message may be expressed in the data represen- 
tation language (e.g., XML) and, in one embodiment, may 
be specified in the schema for the service. As indicated at 
2068, a client may then access and read the set of results 
using the advertisement. 

FIG. 44/ is a flow diagram illustrating a method of 
returning results of a service using an advertisement stored 
in a space according to one embodiment. As indicated at 
2050, a client may send a first message to a service to request 
invocation of one or more functions of the service. In 
response to the first message, the functions) of the service 
may be invoked, as indicated at 2052. The service may then 
generate a set of results, as indicated at 2054. The results 
may be expressed in the data representation language (e.g., 
XML). In one embodiment, the service may store the set of 
results at a location in a space, wherein the space comprises 
a network-addressable storage location. As indicated at 
2056, the service may store the set of results at a location in 
a space, wherein the space comprises a network- addressable 
storage location. As indicated at 2060, the service may 
generate an advertisement for the results. The advertisement 
may include information which is usable to access and read 
the results, such as from the space. For example, the 
advertisement may include a Uniform Resource Identifier 
(URI) at which the results may be accessed. In one 
embodiment, the advertisement may include a schema (e.g., 
an XML schema) which specifies a format of the results. In 
one embodiment, the advertisement may be expressed in a 
data representation language such as XML, As indicated at 
2062, the advertisement may be stored in a space. The space 
may be the same as or different from the space in which the 
results were stored in 2056. A client may read the adver- 
tisement from tbe space, as indicated at 2066. In one 
embodiment, a second client (i.e., a different client than the 
one that sent the message to invoke the functions)) may 
read the advertisement from the space. As indicated at 2068, 
the client may then access and read the set of results from the 
space using the advertisement. 

FIG. 44g is a flow diagram illustrating a method of 
returning results of a service using an advertisement stored 
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in a space and notifying a client using an event according to 
one embodiment. As indicated at 2050, a client may send a 
first message to a service to request invocation of one or 
more functions of the service. In response to the first 
message, the functions) of the service may be invoked, as 
indicated at 2052. The service may then generate a set of 
results, as indicated at 2054. The results may be expressed 
in the data representation language (e.g., XML). In one 
embodiment, the service may store the set of results at a 
location in a space, wherein the space comprises a network- 
addressable storage location. As indicated at 2056, the 
service may store the set of results at a location in a space, 
wherein the space comprises a network-addressable storage 
location. As indicated at 2060, the service may generate an 
advertisement for the results. The advertisement may 
include information which is usable to access and read the 
results, such as from the space. For example, the advertise- 
ment may include a Uniform Resource Identifier (URI) at 
which the results may be accessed. In one embodiment, the 
advertisement may include a schema (e.g., an XML schema) 
which specifies a format of the results. In one embodiment, 
the advertisement may be expressed in a data representation 
language such as XML. As indicated at 2062, the advertise- 
ment may be stored in a space. The space may be the same 
as or different from the space in which the results were 
stored in 2056. As indicated at 2064, an event may be 
generated and sent to the client to notify the client that the 
advertisement for the results is stored in the space. The client 
may read the advertisement from the space, as indicated at 
2066. As indicated at 2068, the client may then access and 
read the set of results from the space using the advertise- 
ment. 

FIG. 45 is a flow diagram illustrating a method of sending 
results of one service to another service in a distributed 
computing environment according to one embodiment. As 
indicated at 2070, a client may send a first message to a first 
service to request invocation of one or more functions of the 
service and to request passage of the results of the functions 
to a second service. A schema for the first service may 
specify a plurality of messages, including the first message, 
which are usable to invoke the functions of the first service. 
The messages and the schema may be expressed in a 
platform-independent data representation language such as 
XML. In one embodiment, the first message may include a 
Uniform Resource Identifier (URI) of an advertisement for 
the second service, wherein the advertisement for the second 
service comprises information which is usable to access the 
second service. 

In response to the first message, the functions of the first 
service may be invoked, as indicated at 2072. The first 
service may then generate a set of results, as indicated at 
2074. The results may be expressed in the data representa- 
tion language (e.g., XML). As indicated at 2076, the first 
service may send the results in a message to the second 
service without sending the results directly to the client. In 
this manner, the results may be efficiently passed from the 
first service to the second service without being passed to the 
client. 

Result spaces and method gates may allow the distributed 
computing environment to provide a simple remote method 
invocation that is practical for thin clients with minimal 
memory footprints and minimal bandwidth, because it need 
not have the adverse side effects of huge program objects 
(along with needed classes) being returned (necessarily) 
across the network to the client as in conventional remote 
method invocation techniques. Instead, results may be 
' returned to a result space, and only if desired (and if they can 
reside on the client) are the actual objects downloaded to the 
client. 
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The mechanism by which the distributed computing envi- 
ronment may provide for remote method invocation is as 
follows (refer also to the description of method gates in the 
Gates section herein). An object may be advertised (e.g. as 

5 a service or as part of a service) in a space. The advertise- 
ment includes a reference that contains the URI (e.g. URL) 
of the object, along with other access parameters, such as 
security credentials and XML schema. A client may have or 
may construct a client method gate for the object, which for 

io every method of the object (or service) itself may have a 
wrapper method that takes the method parameters and 
creates a request XML message to invoke a method of the 
object. The XML message is sent to a service gate which 
invokes the actual method on the service object. When that 

is method returns a result object, the service gate may post the 
result object in a results space, and may return a message to 
the client with a reference to the result object. 

Thus, for a client to invoke a remote method, the client 
first sends a message to instantiate an object (e.g. service), 

20 such as described above. In one embodiment, instantiation 
of an object may include the creation or spawning of a result 
space. In another embodiment, result space creation may be 
independent from the object instantiation. Instantiation may 
return the object URI to the client, and the client and service 

25 gates may be dynamically created when a client requests 
instantiation. In some embodiments, a result space may 
already exist and be advertised by the object (service). Some 
part or all of the gates may also have been p re-constructed 
or reused. 

30 ' Once a client has initiated an object, a local call of the 
appropriate client method gate will affect a remote call to the 
actual remote object, as described above. The remote 
method invocation approach of the distributed computing 
environment may be recursive, with object references 

35 returned to the client, instead of the objects itself, when the 
client gate is called. Note that such returned objects may 
already be instantiated. In some embodiments, the client 
may make a decision to download an entire object itself, 
rather than just remotely invoke it. 

40 A method or service invoked as described above may 
generate a child gate that is associated with the results 
document. The method may return a child gate (or the 
schema, URI and credentials for the client to construct a 
child gate) for the references instead of the references 

45 themselves. The client may then access the references 
through the child gate. The child gate may also be a method 
gate. 

As described above, this remote method invocation pro- 
vided by the distributed computing environment allows the 

50 real result object(s) to be stored in a service results space 
(which also may be created dynamically, by a servlet for 
example). The results space may be temporary. The results 
space may act as a query results cache. The results cache 
may be patrolled by server software (garbage collector) that 

55 cleans-up old result areas. Distributed garbage collection 
may be employed, as result spaces may fill up until they are 
destroyed by a client indicating it no longer needs the space, 
or by an administrator on a server setting appropriate limits. 
Turning now to FIG. 23, an illustration of a default space 

60 350 is provided. The distributed computing environment 
may provide at least one default space so clients can find an 
initial set of advertisements. A device may have a default 
space that exists locally, with a built-in pre-constructed gate. 
The services advertised in that default space may exist 

65 locally on that device, and they may provide system soft- 
ware that enables or facilitates the device's participation in 
the distributed computing environment. 
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The default space 350 may include one or more mecha- less" may refer to a communications, monitoring, or control 
nisms 352 to locate external spaces, as shown in FIG. 23. system in which electromagnetic or acoustic waves carry a 
One service in the default space may run the space discovery signal through atmospheric space rather than along a wire, 
protocol described above to find external spaces. Also, In most wireless systems, radio-frequency (RF) or infrared 
external spaces may be advertised in the default space. 5 (IR) waves are used. Typically, in proximity-based wireless 
Additionally, a service (e.g. a search engine or a proxy systems, a device comprising a transceiver must be within 
service to a search engine) may be advertised in the default range (proximity) of another device to establish and main- 
space that determines or finds external spaces. Each space tain a communications channel. A device may be a hub to 
may be analogous to a file system mount point. Thus, the connect other devices to a wireless Local Area Network 
distributed computing environment may provide searchable, 10 (LAN). 

dynamic mount points to services. A default space may be a As mentioned, embodiments of the distributed computing 

client's initial mount point to the distributed computing environment may provide a mechanism using a lookup 

environment. space that allows clients to rendezvous with services. In a 

A default space or access to a default space may be built proximity computing environment, one embodiment of the 

in to a device. Through the default space and local services is distributed computing environment may provide a service 

that may exist on the device, a client execution environment discovery mechanism that clients may use to discover ser- 

for the distributed computing environment may be provided. vices without using lookup spaces as rendezvous points. An 

Adevice's local services and default space service may have example of a proximity computing environment is an IrDA 

built-in pre-constructcd gates. One of the built-in services point-to-point communications environment. In a proximity 

listed in the default space may be a service to run the 20 computing environment, the proximity mechanism may find 

discovery protocol so that the client may locate additional the "physical" location of the service for the client. For 

(e.g. external) spaces. A default space may include a built-in example, in an IrDA environment, the client device may be 

service that provides an execution environment for clients physically pointed at the device including the service(s) that 

that allows the client user to browse spaces, select, and then the client desires to use. 

instantiate services. Such a service may provide a simple 25 The proximity service discovery mechanism may enable 

user interface that allows a client to entire strings (e.g. the client to directly look for service advertisements rather 

keyword for space searches), view or browse result refer- than sending a lookup request to a lookup space to look for 

ences (e.g. space listings, or service listings within a space), service advertisements. Since the client device may have 

select items (e.g. to chose and instantiate a service), etc. established a proximity connection to the service device, the 

Devices that primarily provide a service may also include 30 client may directly request the desired service. For example, 

a default space and may include a built-in service in the a PDA client device may establish a proximity connection to 

default space that allows a service to manage advertising a printer device; the client may "know" to request a printer 

itself in various spaces. For example, a device, such as a service connection on the printer device, 

printer, may have a built-in default service that finds In one embodiment, the client may send a proximity 

(perhaps through the discovery protocol) a space on a local 35 service discovery message to the service device. The mes- 

area network and adds an advertisement for the printer sage may include information that may specify a desired 

service to that space. This service may also maintain the service on the service device to which the client device has 

printer service advertisement within the LAN space, for a proximity connection. In one embodiment, a service on the 

example, by renewing its lease or updating the printer's service device may respond to the proximity service discov- 

XML schema, etc. 40 ery message, and may send to the client the service adver- 

For some devices that provide a service, the overhead of tisement that the client may use to connect to the desired 

finding a space to advertise its service and maintain that service. The proximity service discovery message may also 

advertisement is undesirable. In one embodiment, rather include information that may be used to authenticate the 

than searching for and maintaining a space or spaces to client and to establish the client's capabilities on the service, 

publish service advertisements, services on some devices 45 Using the received service advertisement, the client may 

may transmit their advertisements in response to connection establish a gate to establish communication with the desired 

requests. For example, a printer device with a printer service service. 

that is available on a proximity basis may not maintain an Nevertheless, it may still be desirable to publish adver- 
advertisement in a space (on the device or external to the tisements for services that do not desire to or cannot main- 
device). Instead, when another device establishes a connec- 50 tain their advertisements in a space that is broadly acces- 
tion with the printer device (for example, a user with a laptop sible. In one embodiment of a distributed computing 
running a client desires to print a document), the printer environment, a device that establishes a connection with a 
service may transmit the service advertisement to provide device that does not publish its service advertisements), 
the XML service schema for connecting to and running the such as a proximity -based device, may publish service 
service that provides printing functionality on the printer 55 advertisements received from the non-publishing device, 
device. Also, some devices may only maintain advertise- For example, a device that establishes a connection with a 
ments for their services in a certain vicinity or local network. proximity-based device and that has an alternate transport 
Such a device may not desire to support or may not have connection(s) may publish (or republish) service advertise - 
access to transports for broader accessibility. ments received from the proximity-based device in the 
One example of a service device in which it may be 60 alternate transport environment, thus allowing the 
desirable for the device to avoid or limit maintaining service proximity-based device service(s) to be used by other 
advertisements in a space is a device whose functionality is devices (through the (re)published service advertisements) 
available on a proximity basis. Proximity-based services which are outside the normal proximity range of the device, 
may provide advertisements of their functionality upon The publishing device may locate a locally published 
request. These advertisements may not be broadly acces- 65 service advertisement for the proximity-based device 
sible. For example, proximity-based services may be pro- through a discovery and/or lookup service, or alternatively 
vided in a wireless communications system. The term "wire- the service advertisement may not be published by the local 
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service device, but instead may be sent to the publishing 
device by the Local device upon the establishment of a 
connection, as described above. In one embodiment, the 
republished service advertisement may be made available as 
long as the device maintaining the advertisement is con- 
nected to or able to connect to the local device. For example, 
if the publishing device is disconnected from the local 
device (for example, moves out of proximity range of the 
device), the service advertisement may be made stale or 
removed. A lease mechanism may be provided to allow the 
space containing the advertisement to send lease renewal 
messages to the publishing device. The publishing device 
may verify its connection to the local device, thus allowing 
the space to detect when the local device is no longer 
available. Rules for how the service advertisements are 
republished may be provided by the local device or by an 
administrative policy for the local vicinity (e.g. roximity 
area) or local network. 

FIG. 24 illustrates an example of a device bridging 
proximity-based devices onto another transport mechanism 
to allow the services provided by the proximity-based 
devices to be accessed by devices outside the proximity 
range of the devices, according to one embodiment. A 
publishing device 1404 may be connected to a network 
1412, such as an Ethernet LAN or the Internet, etc., and may 
establish and maintain proximity connections 1414 with 
proximity devices 1400 and 1404. Proximity connections 
may be wireless connections or wired LAN connections, for 
example. Proximity devices 1400 and 1402 may each send 
a service advertisement to the publishing device 1404 upon 
connection, or, alternatively, the publishing device may 
locate the service advertisements using a discovery and/or 
lookup service for the proximity connections. The publish- 
ing device 1404 may then make the services provided by the 
proximity devices available to other devices 1408 and 1410 
on the network 1412 by republishing the service advertise- 
ments 1416 and 1418 in space 1406. Space 1406 may be 
stored on the publishing device or on other devices con- 
nected to the LAN (including devices 1408 and 1410). 

Other devices on the LAN including devices 1408 and 
1410 may then discover space 1406 and look up the repub- 
lished service advertisements 1416 and 1418 for the 
proximity-based devices, establish gates to communicate to 
those services (device 1404 may act as a proxy or bridge) on 
the proximity-based devices 1400 and 1402 using the XML 
message passing methods described previously, and send 
requests and receive results to the proximity devices. Pub- 
lishing device 1404 may act as a bridge between the network 
1412 and the proximity connections 1414 to the proximity- 
based devices. 
Leases 

Leases may be used in the distributed computing envi- 
ronment to deal with partial failure, resource synchroniza- 
tion (scheduling), and to provide an orderly resource clean- 
up process. Leases may help the overall distributed system 
manage independent clients and services that may come and 
go. The various resources that clients obtain from services 
(including space services) may be leased from those ser- 
vices. In general, not every resource can or needs to be 
leased. In one embodiment, it is up to the implementation of 
each particular service to determine which of its resources 
need to be leased. In particular, resources used by a large 
amount of clients simultaneously may not need leasing or 
instead may require custom leasing protocols. This class of 
leasing may be left to the service provider. Custom 
protocols, such as those to implement transactions for 
example, may be built upon the base leasing scheme. In one 
embodiment, the base leasing model is a relative lime-based 
model. 
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Services may issue leases to clients and provide opera- 
tions on those leases. In one embodiment, all such lease 
functionality of a service is part of that service's XML 
schema. Thus, a client may use its gate (corresponding to the 

5 service and constructed for the service's XML schema) to 
perform lease operations. In one embodiment, all services 
that issue leases provide the following lease operations (only 
allowed by the owner of the lease): (i) renewing a lease 
(parameters specified: lease (e.g. lease ID, lease credential), 

10 new lease time requested), and (ii) canceling a lease 
(parameter specified: lease (e.g. lease ID, lease credential)). 
In one embodiment, all leases are granted for a particular 
amount of relative time (duration of lease) that may be 
negotiated. The requester may specify a certain amount of 

is time (e.g. in seconds), and the grantor may grant the lease for 
any amount up to that time. In one embodiment, a -1 value 
may be used to specify an indefinite lease. 

The leasing mechanism may provide a mechanism to 
detect service and client failure. Leases may also provide a 

20 mechanism to provide shared and exclusive resource access. 
In one embodiment, all service resources either have no 
lease (resource is not leased and therefore available), a 
shared lease (resource accessed by multiple clients), or an 
exclusive lease (resource is accessed by exactly one client at 

25 a time). In one embodiment, all resources begin in the no 
lease state. A no lease state signifies there is no current 
access to the underlying resource, and indicates that there is 
an interest in the resource remaining in existence and thus 
available for leasing. The leasing level may be increased 

30 from none to shared, none to exclusive, or shared to exclu- 
sive. Lease isolation levels may also be decreased from 
exclusive to shared, exclusive to none, and shared to none. 
In one embodiment, clients may voluntarily increase or 
decrease the lease isolation level, or may be requested by the 

35 service to do so. A response message from the service may 
indicate if the isolation level change was accepted. 

Request-response message pairs may be employed to 
claim, release, and renew a lease. Each message may be 
tagged using a reserved XML tag to indicate that the 

40 message is a leasing message. The complete composition of 
the message isn't necessarily defined by the distributed 
computing environment. In such an embodiment, service 
developers may append custom message content, as long as, 
the message is tagged as a leasing message. 

45 In one embodiment, clients that use leased resources may 
be expected to: (i) claim the resource as shared or exclusive, 
(ii) release the resource claim (if requested or if finished with 
resource), and (iii) respond to renewal messages (with 
another claim at same or different isolation level). Renewal 

50 messages may be sent (e.g. in regular intervals) by services 
to detect client failure cases. The interval (at which the 
renewal message is sent) may be service specific. If a 
response to the renewal message isn't issued after a specific 
amount of time (e.g. based on a time noted in the service 

55 advertisement), a resource reclamation process may begin 
within the service, revoking the lease completely. In such an 
embodiment, renewal messages sent to clients should be 
handled in a timely fashion. FIG. 25 illustrates the use of 
renewal messages both between a client and an instantiated 

60 service and between a service provider and a space service. 
Note that both cases may be considered as the use of renewal 
messages between a client and a service, since a service 
provider may be a client to a space's advertisement service. 
Renewal messages may arrive in an "out of band" fashion 

65 that may be inconvenient for the client to handle. That is, the 
client cannot predict when a renewal message will be sent 
from the service. Out of band message handling may com- 
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plicate the client's logic and increate its complexity. To solve 
this problem, an automatic lease renewal mechanism may be 
implemented to relieve the client of the responsibility of 
handling the out of band messages, and thus reduce client 
complexity. In the automatic lease renewal mechanism, each 5 
gate (message, method, and/or event gate) may receive 
renewal messages and automatically respond to them with- 
out help from the client. The default response to a renewal 
request is to claim the lease at its current level. Each 
message gate may contain a single, set-aside renewal 10 
response message that is automatically sent to the adver- 
tisement space service when the gate receives the renewal 
message. This "out of band" message is handled on behalf 
of the client, yielding a cleaner client programming model. 
In one embodiment, the gate may allow clients to register 15 
lease event handlers to specify different isolation levels in 
the response message. 

The leasing mechanism may also provide a mechanism to 
detect stale advertisements. When a service publishes its 
advertisement in a space, that service obtains a lease on this 20 
publishing of its advertisement. Each advertisement may 
contain a time by which the service promises to renew the 
advertisement. In one embodiment, all time-out values are 
specified in seconds. If the service continues to renew its 
lease, the space is provided some assurance that the service 25 
advertised is still being offered. The renewal time may be 
counted down towards zero by the space service. If the 
service does not renew its lease, the service may have failed, 
or it may no longer wish to, or be able to provide the service. 
When the lease is not renewed, the space service marks the 30 
service advertisement stale, so it does not make it available 
to clients. Services renew advertisements by sending a 
renewal message to the space. The space service receives 
these messages and re-sets the advertisement renewal time 
back to its initial value. 35 

In one embodiment, stale advertisements are not auto- 
matically deleted. Depending upon the policies of the space, 
it may choose to delete stale service advertisements that 
have expired for a reasonably long period of time. The 
deletion policy may be set by the space service. The space 40 
service may search for stale advertisements and either delete 
them or bring them to the attention of an administrator, for 
example. 

In addition to detecting stale advertisements, the space 
service may use leases to manage the resources its facilities 45 
provide to clients (including other services) of the space. For 
example, when a client desires to use a service, the space 
service may request a lease for the client as part of service 
instantiation. Service instantiation may be performed to 
allow a client to run a service. To instantiate a service, a 50 
client may first select one of the service advertisements 
published in a space. The client may use the various facilities 
provided by the space to look up advertisements in the 
space. Then the client may request the space to instantiate 
the service. The lease acquired during service instantiation is 55 
on use of the service advertisement (not the same as the lease 
on publishing of the service advertisement). It should be 
noted that the space service may allow multiple clients to 
have a lease on use of a service advertisement if the 
advertisement has an indication it is shared. Otherwise, the 60 
space service only allows one client at a time to have a lease 
on the service advertisement (exclusive). 

Another example of how a space service may uses leases 
to manage the resources its facilities provide to clients is 
when a client of the space registers to be notified when XML 65 
documents (e.g. service advertisements) are added or 
removed from a space. The registering client of the space 
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may obtain a lease on this subscription to notifications. This 
lease enables the space service to know whether to continue 
sending notifications. Such a lease may not be necessary 
when a client has established an active session with the 
space. Also, note that when a client of a space (could be a 
service) establishes a session with the space, the client may 
obtain a lease on the session. This allows the space to 
manage any resources associate with the session. 

In another embodiment, the distributed computing envi- 
ronment may employ a leasing mechanism that is not 
time-based. The lease may be generated when an object is 
claimed for use. Instead of a time-based mechanism, the 
claim method may accept a callback that notifies the current 
leaseholder that some other party wishes access the same 
object (e.g. service). Thus, as an alternative embodiment to 
time-based leases, instead clients may make claims on space 
objects (e.g. services). When another client desires a lease 
that is incompatible with the current leaseholder's, the 
service may send a "callback message" to the client. Upon 
receiving the callback message, the client (i.e. client gate) 
may invoke a callback method to decide on a response to the 
callback message (keep the lease, cancel the lease, change 
the access level to shared, etc.). Once a response has been 
determined, the client gate sends a response message to the 
service. This distributed mechanism for managing leases 
may be implemented using the XML message-passing layer. 
Authentication and Security 

The distributed computing environment provides for 
spontaneous and heterogeneous distributed systems based 
upon an asynchronous message passing model, where data 
and/or objects may be represented in a representation lan- 
guage such as XML. In the distributed computing 
environment, clients may connect to services throughout the 
Internet, for example. The distributed computing environ- 
ment may enable large numbers of network devices to work 
together in a reliable, dynamic, and secure fashion. The 
distributed computing environment may define a protocol 
that substantially enables interoperability between compli- 
ant software components (clients and services). 

In the context of the distributed computing environment, 
a device may be a networking transport addressable unit. 
Clients and services may be implemented as Universal 
Resource Identifier (URI) addressable instances of software 
or firmware that run on devices. 

Internet space is inhabited by many points of content, A 
URI is a method used to identify any of those points of 
content, whether it be a page of text, a video or sound clip, 
an image, software, firmware or other Internet content. The 
most common form of URI is the Web page address, which 
is a particular form or subset of URI called a Uniform 
Resource Locator (URL). A URI typically describes the 
mechanism used to access the resource, the specific com- 
puter that the resource is housed in and the specific name of 
the resource (typically a file name) on the computer. 

Clients and services (both may be implemented on 
devices as software and/or firmware) may be connected over 
the Internet, a corporate intranet, a dynamic proximity 
network, within a single computer, or by other network 
connection models. The size and complexity of the devices 
supporting clients and services may range, for example, 
from a simple light switch to a complex, highly available 
server. Example devices include, but are not limited to: 
PDAs; cellular phones; notebook, laptop, and more powerful 
PCs; and more powerful computer systems, up to and 
including supercomputers. In some embodiments, the 
distance, latency, and implementation of clients and services 
may be abstracted, with a common discovery and commu- 
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nicatioo methodology, creating a "black box" effect. This 
definition approach allows software implementation issues 
to be dealt with by the underlying platform, yielding a 
loosely coupled system that may be scaled to Internet 
proportions. 5 

The distributed computing environment may provide an 
Internet-centric programming model including WEB and 
XML content representation, dynamic device discovery, and 
secure device communication that is accessible from a wide 
range of network devices. The distributed computing envi- 10 
ronment may include a network programming model 
abstracted above the CPU level. The programming model 
may include the following properties: 

URI addresses 

Strongly typed data called content (addressed with URIs) 15 

Substantially unlimited amount of persistent content stor- 
age ( e *g- stores), (containing XML and non-XML 
content, such as that identified by MIME types) 

Substantially unlimited amount of transient content 2Q 
memory called spaces (containing XML content) 

Descriptive XML metadata (data about data) content 
advertisements that may be stored in a space to notify 
interested clients. 

A substantially unlimited number of instructions 2 5 
(embodied as messages) 

Secure message endpoints (gates) addressed by URIs 

Data flow support (event messages) to coordinate work 
flow between distributed software programs 

Services and clients may run as programs within the 30 
distributed computing environment. Services may advertise 
their capabilities to clients wishing to use the service. Clients 
may or may not reside within the same network device, and 
that device's code execution environment may or may not 
support the Java platform. 35 

Using URIs to address content and message endpoints 
gives the distributed computing environment a powerful 
addressing scheme. The address may specify the location of 
the content or endpoint, and may specify the route (or 
transport protocol) to be used. Items addressed using URIs 40 
also may have an associated security credential. The security 
credential may be used to control what clients are allowed 
access to the item, as well as which operations authorized 
clients are allowed to perform on that item. 

The high degree of access provided by the distributed 45 
computing environment may be controlled by appropriate 
authorization and security systems and methods. Authenti- 
cation and security in the distributed computing environ- 
ment may include, but are not limited to: verifying the 
typing correctness of XML content in a message; securely 50 
identifying the sender to the receiver; a mechanism to check 
the integrity of messages sent from a client to a service and 
vice versa; and a mechanism of describing a service's set of 
accepted messages to a client and enforcing the message 
requirements on messages received at the service. The above 55 
listed security and authorization features may be leveraged 
in a single, atomic unit of code and data. The atomic unit of 
code and data may be dynamically created. In one 
embodiment, once created, the atomic unit of code and data 
may represent a message endpoint (gate), and may not be 60 
altered as to the security and authorization policies imple- 
mented during creation. 

A gate may represent the authority to use some or all of 
a service's capabilities. Each capability may be expressed in 
terms of a message that may be sent to a service. Gates may 65 
also be used for failure case detection when a client leases 
resources. 
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Authorization and security may also include a mechanism 
for verifying that a client attempting to use a service is 
authorized to use the service; that the space from which the 
client receives the service advertisement from is authorized 
to provide the service advertisement; and/or that the service 
advertisement itself is authorized. 

Message passing may be implemented in a messaging 
layer as the means of communicating requests from clients 
to services and of the services responding with results to the 
clients. The messaging layer of the distributed computing 
environment may substantially guarantee that valid XML 
messages are sent, and may provide mechanisms enabling a 
language -independent security model. In the messaging 
layer, a sending message endpoint may be linked to a 
receiving message endpoint. The two associated message 
endpoints may provide a secure, atomic, bidirectional mes- 
sage channel suitable for request-response message passing 
between a client and a service. 

In embodiments of a distributed computing environment, 
an advertisement may be published in a space for a service. 
An advertisement may be an XML document that includes 
the XML schema and URI of the service. The service may 
also include a service ID token or credential in the 
advertisement, and may specify in the advertisement an 
authentication service to be used by both the client and the 
service. A client may then locate the service advertisement 
on the space, and use the advertisement to instantiate a 
message gate on the client. The client may use the authen- 
tication service specified in the advertisement to obtain an 
authentication credential for sending in messages to the 
client. In one embodiment, the client may pass the service ID 
token or credential from the service advertisement to the 
authentication service, and the authentication service may 
then use the service token or credential to generate the 
authentication credential for the client. In one embodiment, 
the client may include a gate factory that receives the 
necessary information to create the message gate, and the 
gate factory may construct the message gate and communi- 
cate with the authentication service to obtain the authenti- 
cation credential for the client. A corresponding service 
message gate may be instantiated at the service. 

The client, at some point, sends a first message to the 
service. In one embodiment, the client message gate may 
embed the client's authentication credential constructed by 
the authentication service in the message. When the service 
receives the message, it may use the same authentication 
service to verify the authentication credential received in the 
message. By sharing the same authentication service, any of 
a variety of authentication protocols may be employed, with 
the details of generating the authentication credentials sepa- 
rated from the client and the service. Thus, a client may use 
different authentication credential protocols with different 
services. 

In one embodiment, the authentication service may deter- 
mine the capabib'ties of the client (e.g. what the client is 
allowed to do on the service) upon first receiving the client 
authentication credential from the service. The capabilities 
of the client may be bound to the client's identity. Then, the 
client's message gate may embed the authentication creden- 
tial in every message sent from the client to the service. The 
messages may be received by the service message gate and 
then checked by the authentication service to ensure that the 
message is from the client and that the message request is 
within the capabilities of the client. In another embodiment, 
capability determination and message checking for capabili- 
ties may be handled by the service message gate without 
using the authentication service. 
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The client and service message gates may work together 
to provide a secure and reliable message channel. The gates 
may serve as secure message endpoints that allow the client 
to run the service by sending and receiving secured, autho- 
rized XML messages to and from the service. 5 

Operations in the distributed computing environment may 
be embodied as XML messages sent between clients and 
services. The protocol used to connect clients with services, 
and to address content in spaces and stores, may be defined 
by the messages that can be sent between the clients and 
services. The use of messages to define a protocol may 
enable many different kinds of devices to participate in the 
protocol. Each device may be free to implement the protocol 
in a manner best suited to its abilities and role. 

A service's capabilities may be expressed in terms of the ^ 
messages the service accepts. A service's message set may 
be defined using an XML schema. A XML message schema 
may define each message format using XML typed tags. The 
tag usage rules may also be defined in the schema. The 
message schema may be a component of an XML adver- 2Q 
tisement along with the service's message endpoint (gate) 
used to receive messages. Extensions (more capabilities) 
may be added to services by adding messages to the XML 
message schema. 

In the distributed computing environment, authorized 25 
clients may be able to use all of a service's capabilities, or 
may be limited to using a subset of the service's capabilities. 
In one embodiment, once a set of capabilities has been given 
to a client, the client may not change that set without proper 
authorization. This model of capability definition may allow 3Q 
for services levels that run from a base set of capabilities to 
an extended set. 

Service instantiation may be performed to allow a client 
to run a service. To instantiate a service, a client may first 
select one of the service advertisements published in a space. 35 
The client may use the various facilities provided by the 
space to look up advertisements in the space. Then the client 
may request the space to instantiate the service. Service 
instantiation may include, but is not limited to, the following 
steps: ^ 



1. Client requests space service to instantiate a service. 

2. Space service verifies client is allowed to instantiate the service. 

3. Space service obtains a lease on the service advertisement for the 45 
client with the lease request time specified by the client. 
Alternatively, the service advertisement may be provided to the cli- 
ent 

without using the leasing mechanism. 

4. Space service sends a message to the client that includes the lease 
allocated in steps 3, and the service advertisement of the service. 

5. Client runs the authentication service specified in the service 50 
advertisement, and obtains an authentication credential. 

6. Client constructs a client message gate for communicating with the 
service. 



In order to provide trust between clients and services in 55 
the distributed computing environment, a series of dynami- 
cally generated numbers (keys, or tokens) may be used as 
security or authentication credentials for clients. One or 
more credentials may be used to verify the right of a client 
to use a service and to verify messages between the client 60 
and the service. Each client and service may have a unique 
credential. 

The type of authentication credential needed to use a 
service may be returned to the client conducting a service 
search. In one embodiment, an authentication credential is 65 
an opaque object that must be presented each time a client 
uses a service. In one embodiment, the authentication cre- 



dential may be presented by a message gate on behalf of a 
client in every message sent to a service. No matter what 
kind of authentication credential is required by a service, by 
using an authentication service external to the client and the 
service, the client and the service may not need to be aware 
of the authentication credential structure or of the authenti- 
cation process. 

An authentication credential may also include a transport- 
specific ticket in addition to the service ticket. When running 
a service, depending upon the networking transport specified 
in the service advertisement, the transport may provide a 
secure connection. In some cases, if the data link layer is 
already secure, it may not be necessary to use a secure 
transport over the already secure data fink layer. 

The concept of an authentication credential is abstract 
enough to allow various levels of security based upon 
credential implementation. Levels of security may include, 
but are not limited to: 



1. None (no message security - credential is empty or no credential) 
Messages with empty credentials or no credentials may be sufficient 
when security is enforced by the physical connectivity properties of 
the transport. For instance, a smart light switch connected to jusl one 
light switch controller is secure because the switches are wired in a 
secure manner. 

2. Signed messages (digital signatures) 

Signed messages may include a digital signature that enables the 
service (receiving the message) to verify the origin (client) of the 
message. 

3. Encrypted messages (transport may handle this) 

Encrypted messages add another level of security by scrambling the 
message contents so that another credential is required to unscramble 
it. 

4. Capability messages (service functionality and user aware) 

This level of security may provide for security capabilities on a user- 
by-user basis (e.g. what the user is allowed to do), and may allow 
for 

fine-grained access control to services and individual service 
functions. 



Multiple levels of security zones may be used, due to the 
heavyweight implementation necessary to enforce the 
higher levels of security (capabilities & encryption). If the 
message transport supports (or helps support) these security 
levels, the support may be leveraged to provide security 
level bridge services that bridge one level of security to 
another. 

As mentioned above, services without any security model 
may accept empty authentication credentials. For services 
that do not restrict access, a gate may be built without an 
authentication credential or with an "empty" authentication 
credential. The gates for such services may not send an 
authentication credential with each message, or may send an 
empty credential. The authentication service is one example 
of a service that may not restrict access. Other services may 
require a user and password pair. 

In some embodiments, a mechanism for verifying that a 
client attempting to run a service, for verifying that the 
service advertisement received by the client is an authorized 
service advertisement, and for verifying that the space from 
which the client received the service advertisement is autho- 
rized may be based upon a public key/private key asym- 
metric cryptographic mechanism. In this mechanism, an 
authorized sending entity may embed a public key in a 
message and encrypt the message including the public key 
with its private key. An entity receiving the encrypted 
message may decrypt the message using the public key and 
find the same public key embedded in the decrypted 
message, and thus verify that the message is from the 
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authorized entity, since only that entity has the private key 
necessary to encrypt the message. Thus, an entity may issue 
a credential that is substantially unforgeable, and that other 
entities may decrypt (with the appropriate public key) to 
verify messages sent by the entity. 

A Kerberos ticket is one example of a security credential 
that may be used in the distributed computing environment. 
Kerberos is a secure method for authenticating a request for 
a service in a computer network. Kerberos lets a user request 
an encrypted "ticket" from an authentication process that 
can then be used to request a particular service. The user's 
password does not have to pass through the network. 

Mechanisms may be provided by the distributed comput- 
ing environment to substantially guarantee that messages 
sent between clients and services are not compromised. In 
one embodiment, a sender may embed a token containing 
information that may be used by the receiver to verify that 
the message has not been altered. There are several methods 
for generating the information to embed in the message. In 
one embodiment, a hash of the message may be computed 
and sent with the message. Hashing may include the trans- 
formation of a string of characters into a usually shorter 
fixed-length value or key that represents the original string. 
Upon receiving the message, the receiver may recompute the 
hash and check it against the sent hash. If the message has 
been altered, it is highly unlikely that the same hash will be 
generated. The sender may encrypt the hash and send the 
corresponding public key in the encrypted message to sub- 
stantially ensure that the hash is not compromised. 

In other embodiments, an error detection scheme such as 
cyclic redundancy checking may be used. Cyclic redun- 
dancy checking is a method of checking for errors in data 
that is transmitted on a communications link. In an embodi- 
ment using cyclic redundancy checking, the sender applies 
an n-bit polynomial to the message and appends the result- 
ing cyclic redundancy code (CRC) to the message. The 
receiver applies the same polynomial (which may also be 
passed in the message) to the message and compares its 
result with the result appended by the sender. If they agree, 
the message has been received successfully. If not, the 
sender may be notified to resend the message. 

Gate factories may also play a role in security, since a gate 
factory may be "trusted" code. Using a trusted gate factory 
to generate gates may help to ensure that gates are trusted 
code, and that the code is correct with respect to the service 
advertisement. Clients may be required to present a client ID 
token or credential to the gate factory as a means of 
authentication. Services may present a service ID token or 
credential to clients (e.g. through an advertisement) when a 
client wishes to create a gate. As discussed herein, a client 
and service token pair may be used to create a third 
credential that may be used to allow the client to send 
messages to the service. This third credential may be 
referred to as an authentication credential. An authentication 
credential may be created by an authentication service 
during the authentication process. In one embodiment, the 
service may use any authentication policy at its disposal. In 
one embodiment, the authentication service administers the 
authentication policy on behalf of the service, and thus the 
service does not have to be aware of the particular authen- 
tication policy being used. 

The client may construct its gate using an authentication 
credential that the client receives by running an authentica- 
tion service specified in the service advertisement. This may 
allow the constructed gate to send the authentication cre- 
dential with each message to the service. When the service 
receives the first authentication credential in a first message 
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from the client, the service may use the authentication 
service specified in the service advertisement to authenticate 
the client, and thus may establish a binding of the authen- 
tication credential to the identity of the client. 

5 As previously discussed, some results produced by a 
service may be advertised in a space and ultimately accessed 
using a results gate. The results gate may or may not contain 
the same security credential as the input gate used to 
generate the results. Because input to a service may be 
asynchronous from its output (the results), the results may 
have a different set of access rights associated with it. For 
example, a payroll service may allow a different set of 
clients to initiate payroll than to read the payroll service's 
results (paychecks). Thus, a client may have to go through 
a separate authentication process to obtain access rights to 

15 the results, which may include receiving an authentication 
credential for the results from an authentication service 
specified in an advertisement for the results. 

Message gates may offload most security checks from 
services. Services may focus on providing capability and 

20 authenticating clients. A principle of least privilege may be 
supported by giving clients access to only those capabilities 
that are requested (or assigned). 

Security checks may occur when a gate is created and/or 
when a gate is used (when messages are sent and/or 

25 received). When a client requests access to an advertised 
item (service), the process of gate creation may begin. 
During this process, the client gate factory may work with 
the service to mutually authenticate each other. The checks 
performed at gate creation time may be extensive, and may 

30 minimize the number of checks performed during gate 
usage. After the service has authenticated the client, the 
service may determine specific capabilities for the client 
(e.g. what the client is allowed to do on the service), and 
associate the capabilities with the client's authentication 

35 credential. These specific capabilities may specify what 
operations the client is allowed to perform on the service. 
Since the gates may ensure that every message contains the 
authentication credential, the service can then check each 
request when it is received against the capabilities of the 

40 authenticated client. 

Gate creation checks may ensure that a client has permis- 
sion to use some or all of the service capabilities designated 
by the XML message schema. In one embodiment, these 
checks may be implemented using access control lists 

45 (ACLs) in conjunction with an authentication service such 
as Kerberos. A challenge -response sequence (such as a 
password) may also be used to authenticate a client. 

In one embodiment, whatever means is used to authenti- 
cate the client, the authentication may be invisible to both 

50 the client and service, the gate factory may be aware of 
which authentication service to use, and the authentication 
service handles the authentication mechanism and policies. 
Gate factories may be product and environment dependent, 
or may even be controlled by a configuration management 

55 system. In one embodiment, the degree and method of client 
isolation may be platform dependent, but is known to the 
gate factory. 

Message gates in the distributed computing environment 
are typically associated with a single client. The means of 

60 association may be determined by the gate factory. The 
checks performed at message send time may ensure that the 
proper client is using the gate. In one embodiment, gates 
may be passed in messages, and may be cloned if a new 
client wishes to use the gate. The cloning process may 

65 perform a new set of creation checks. 

Once a client of a space (the client may be another 
service) finds the advertisement of a space service, the client 
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of the space may run the space service, as it would any other the spawned space, so that the authentication service 

service. Running a space service may involve using an only authenticates the root authentication token, and so 

authentication mechanism. Running a space service may that it returns no other authentication tokens (no other 

include, but is not limited to: clients of the spawned space allowed initially). 

5 Initializing the security policies of the spawned space so 
that the root identity associated with the root authen- 
tication token has access to all facilities of the space, 

1. The client of the space may first run an authenucation service that including the security administration facilities, 
may be specified in the service advertisement of the space service o lLJW ^ aunuuioiiauwu 

to obtain an authentication credential As indicated at 1958, returning the root authentication 

2. The client of the space may use the authentication credential, the iq token and the service advertisement of the Spawned 
XML schema of the space (from space's service advertisement), and tQ the requestor of the S p awne d Space. 

the URI of the space (from space s service advertisement) to ™ , . j 

construct a gate for the space, in one embodiment, the client The requestor may build a gate to access the spawned 

may pass the information to a gate factory to construct the gate. space, since it is returned the authentication credential and 

3. The client of the space may mn the space service by using the gate the service advertisement of the spawned space. In one 
^send messages to the service. 15 embodiment, only the requestor and clients or services that 

4. When the space service receives the first message from the client, the requester passes the authentication credential and the 
with the authentication credential embedded, the space service may spawned space's service advertisement may access the 

use the same authentication service used by the client to obtain the spawned Space, Such limiting of access to the Spawned 

authentication credential to authenticate the client, thus establishing r f c t u i ■ . j • • *u . 

the client's identity space may be useful when a client and service are usmg that 

5. The space service may then determine the client's capabilities (e.g. 20 Spawned Space to Store results, for example, if the client and 
what the client is allowed to do on the space service) and bind the service desire to keep the results private. 

capabilities to the authentication credential. In one embodiment, the requesting client may send the 

root authentication token to a second client (including a 

As discussed in the Spaces section, a space's facilities service acting as a client of the space service). The second 

may include an interface for spawning an empty space with 25 client may then access the second space by sending to the 

substantially the same functionality (same XML schema) as second space at least one of the messages specified in the 

the space from which it is spawned. The spawning facility second schema along with the root authentication token, 

may be useful, among other things, for dynamically gener- After running a service, the client may change the authen- 

ating spaces for results. tication policies of the spawned space using a security 

FIG. 42 is a flow diagram illustrating the secure spawning 30 administration space facility, and other clients or services 

of a new space in a distributed computing environment may tnen access the spawned space. The other clients may 

according to one embodiment. As indicated at 1950, a client then have access to the second space SCTvi ce, ^ that , for 

may access (e g., connect to) a first space service. (Aservice example, the other clients may read service advertisements 

may act as a client for the purpose of accessing or otherwise from tQe , n addid ^ ed , s 

using a space.) As indicated at 1952 the creation of a second 3J adverlisement be made availa51e t0 other clients 

space may be requested, such as by the client sending an - iL . /t [ lL ,. 4 , x 

appropriate request to an interface of the first space. Achent of . the *P* wned s P ace < the f*™ ? hcn{s ^ be services > 

(including a service acting as a client of a space service) usm £ the discovery protocol or other means, 

which requests creation of the space may be referred to as ™* messa ^ transport layer in a distributed computing 

the requesting client. In response, a second space service environment may include mechanisms for protecting the 

with a second space may be created at a second Internet 40 security and integrity of communications among clients and 

address, as indicated at 1954. As above, the second space services during transport. This security may be referred to as 

service may include a second schema which specifies one or "wire security" or "transport security" to distinguish it from 

more messages usable to invoke functions of the second the authentication security implemented by the messaging 

space service. The second schema may include at least the system including gates. Encryption of messages may be 

first schema, and the second schema may include additional 45 provided at the message transport layer of the distributed 

functionality as well. computing environment. Services that request an encrypted 

The second space may initially be configured to permit transport may do so by tagging the XML advertisement. The 

access only to the requesting client. In one embodiment, as gate factory may then create a gate (or gates) that uses a 

indicated at 1956, a root authentication token is created for secure message transport such as those provided by Blue- 

the second space. Also as indicated at 1956, an authentica- 50 tooth and HTTPS. 

tion service associated with the second space may be HTTPS (Secure Hypertext Transfer Protocol) is a Web 

initialized, whereby the second space is configured to permit protocol that encrypts and decrypts user page requests as 

access only to a client holding the root authentication token. well as the pages that are returned by the Web server. 

As indicated at 1958, the root authentication token may be HTTPS uses a 40-bit key size for the RC4 stream encryption 

sent to the requesting client or service. As indicated at 1960, 55 algorithm, which is considered an adequate degree of 

the requesting client may then access the second space by encryption for commercial exchange. HTTPS may be used 

sending to the second space at least one of the messages as a transport in the distributed computing environment, 

specified in the second schema and by using the root Bluetooth is an emerging peer-to-peer wireless commu- 

authentication token. nications standard. The Bluetooth key generation algorithms 

In one embodiment, therefore, when a requester has 60 may be used in the distributed computing environment, 

spawned a space, only the requestor may be allowed to Bluetooth may support encryption keys. Encryption keys are 

access the spawned space. For example, the spawned space transport dependent, while client, service, and combination 

may be for storing results from a service that the client needs keys may be transport independent, 

to keep secured. In one embodiment, this security may be FIG. 26a — An Authentication Service Providing an Authen- 

ensured by: 65 tication Credential to a Client 

As indicated at 1956, creating an initial root authentica- FIG. 26a is a flow diagram illustrating an authentication 

tion token, and initializing the authentication service of service providing an authentication credential to a client 
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according to one embodiment. A client in the distributed 
computing environment may desire a service to perform one 
or more functions on behalf of the client. In one 
embodiment, an authentication service may be provided for 
use by the client and the service when setting up a secure 
messaging channel. An authentication service may perform 
functions for the client and/or service including authenticat- 
ing the client and/or service and negotiating the desired level 
of security and the set of messages that may be passed 
between the client and service. The authentication service 
may be a process that is executing within the distributed 
computing environment, The authentication service may be 
executing on the same device as the service and/or the client, 
or alternatively the authentication service may be executing 
on a separate device such as an authentication server. In one 
embodiment, the authentication service may be an Internet- 
based service. The authentication service may have its own 
address, for example, a Universal Resource Identifier (URI), 
through which the client and/or service may communicate 
with the authentication service. In one embodiment, the 
address of the authentication service may be provided to the 
client in the service advertisement for the service. The client 
and service sharing an authentication service may help 
insure that a secure messaging channel may be established 
between the client and the service, as any of several security 
and authentication protocols may be used in the messaging 
channel. 

In one embodiment, a client may present a client identi- 
fication token or credential to an authentication service. The 
client token or credential may be sufficiently unforgeable to 
be used as proof of the client's identity. The authentication 
service may then check the client identification token or 
credential, and issue to the client an authentication credential 
that only the authentication service can create. The authen- 
tication credential that is returned to the client is then sent in 
every message by the client to the service. In one 
embodiment, the client message gate is created by a gate 
factory, which includes the authentication credential in the 
message gate, and thus the message gate includes the 
authentication credential in every message that it sends to 
the service on behalf of the client. When receiving a 
message, the service may then check the authentication 
credential. Since only the authentication service can create 
the authentication credential, the service knows that the 
client did not forge the authentication credential. In one 
embodiment, the service may pass the authentication cre- 
dential to the same authentication service used by the client 
to ensure the authentication credential is valid, to verify that 
the client is an authorized client, and to find out the identity 
of the client. 

All services, including space services and authentication 
services, may authenticate their clients. Once a service 
authenticates a client, the client may access the service. For 
example, in the case of a space service, a client may then 
obtain XML advertisements from the space. 

In one embodiment, a service may have a prearranged 
credential that all clients of the service are to use. In this 
embodiment, the authentication may provide the prear- 
ranged credential to a requesting client. Any client present- 
ing the prearranged credential to the service may be 
approved by the service. 

In step 1000, the client may request an authentication 
credential from the authentication service. In one 
embodiment, the client may search for and locate a service 
advertisement for the desired service. In one embodiment, 
the service advertisement may include an advertisement for 
the authentication service to be used to obtain an authenti- 
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cation credential to be used in accessing the service. In one 
embodiment, the service advertisement may include an 
address such as a URI for the authentication service. In one 
embodiment, the client may send information to the authen- 

5 tication service requesting the authentication credential. In 
one embodiment, the client may send information to a gate 
creation process, for example, a gate factory, and the gate 
creation process may access the authentication service to 
obtain the authentication credential. 

30 In step 1002, the authentication service may generate an 
authentication credential for the client. The authentication 
credential may be a data element or data structure that may 
be embedded in messages in a messaging system and that 
may allow receivers of the messages to authenticate the 

15 sender of the message, to verify the message is from an 
authorized sender, and to verify that the message is a 
message the sender is allowed to send to the receiver. In one 
embodiment of a distributed computing environment, an 
authentication credential may be unique to the messaging 

20 channel set up between a particular client and a particular 
service. Step 1002 is further illustrated and described in FIG. 
26b. In step 1004 of FIG. 26a, the authentication service 
may return the authentication credential to the client. In one 
embodiment, the authentication credential may be returned 

25 directly to the client. In one embodiment, the authentication 
credential may be returned to a gate creation process, for 
example, a gate factory, which may then use the authenti- 
cation credential in generating a gate. 
FIG. 26b — An Authentication Service Generating an 

30 Authentication Credential 

FIG. 26b is a flow diagram expanding on step 1002 of 
FIG. 26a and illustrating an authentication service generat- 
ing an authentication credential according to one embodi- 
ment. In step 1002a, in one embodiment, the authentication 

35 service may obtain a client token and a service token. In 
another embodiment, the authentication service may obtain 
only a client token. In one embodiment, the client token may 
be a unique identifier for the client in the distributed com- 
puting environment. In one embodiment, the service token 

40 may be a unique identifier for the service in the distributed 
computing environment. For example, the public keys from 
a public/private key encryption mechanism may be used as 
unique identifiers for the client and the service. In one 
embodiment, the client may receive the service token in the 

45 service advertisement, and the client may provide the client 
token and the service token to the authentication service. In 
another embodiment, the client may provide the client token 
and the service advertisement URI to the authentication 
service, and the authentication service may retrieve the 

50 service token from the service advertisement. 

In step 10026, the authentication service may verify the 
client and/or the service. In one embodiment, the authenti- 
cation service may use the client token and the service token 
obtained in step 1002a to verify the client and/or service. In 

55 another embodiment, only a client token was obtained in 
step 1002a, and thus only the client token is used to verify 
the client in step 10026. In one embodiment, the client may 
have previously registered its client token with the authen- 
tication service, and the authentication service may compare 

60 the received client token to the registered client token to 
verify the client as a valid client. In one embodiment, the 
client may access the authentication service using a 
challenge/response mechanism such as a logon account with 
password and thus may be verified as a valid client. In one 

65 embodiment, the service may have previously registered 
with the authentication service, and may have provided its 
service token to the authentication service. The authentica- 
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tion service may then verify thai the client is attempting to 
access a valid service by comparing the received service 
token to the previously registered service token. Other types 
of client and service authentication may also be used. For 
example, the client may provide a digital signature or digital 
certificate that the authentication service may use to authen- 
ticate the client and/or to authenticate the service the client 
is trying to access. 

In step 1002c, the authentication service may generate an 
authentication credential. In one embodiment, the authenti- 
cation credential may generate an authentication token that 
only the authentication service can create. In one 
embodiment, the authentication service may use the client 
token and the service token in generating the authentication 
credential. In another embodiment, the authentication ser- 
vice may use just the client token to generate the authenti- 
cation credential. In yet another embodiment, the authenti- 
cation service may not use an obtained token in the 
generation of the authentication credential, but may instead 
use an authentication credential generation algorithm to 
generate a substantially unforgeable authentication creden- 
tial. In one embodiment, the authentication service may 
combine the service token and client token to create a unique 
authentication credential. For example, the service token and 
client token may be 64-bit values, and the two tokens may 
be combined to generate a 128-bit authentication credential. 
Other embodiments may use other methods to generate an 
authentication credential. 

Bridging Devices to the Distributed Network Environment 
' There may be devices, external to the distributed com- 
puting environment, which do not support the message 
passing model implemented by the distributed computing 
environment. These devices may provide services that may 
be useful to clients in the distributed computing environ- 
ment. The distributed computing environment may include 
a mechanism to bridge such external devices to the distrib- 
uted computing environment so that the services offered on 
such devices may be accessed by clients in the distributed 
computing environment. The distributed computing envi- 
ronment may also leverage existing device discovery pro- 
tocols for discovering such external devices for use in the 
distributed computing environment. 

Many technologies define discovery protocols for pub- 
lishing and monitoring a network's device composition. 
These technologies include, but are not limited to: Jini, SLP, 
Bluetooth, and UPnP, Furthermore, many I/O buses such as 
LonWorks, USB and 1394 also support dynamic discovery 
protocols. The distributed computing environment may 
leverage device discovery technologies by wrapping their 
implementations in an API. Leveraging other device discov- 
ery protocols and providing a method to bridge to other 
discovery protocols may allow the distributed computing 
environment to discover devices or services on a wide 
variety of network and I/O buses. Device discovery in the 
distributed computing environment may thus be applicable 
to a wide range of devices including small devices such as 
PDAs, even if they do not participate directly in the distrib- 
uted computing environment. Discovery protocols may be 
defined at the message level. 

A bridging mechanism may be provided for "wrapping" 
one or more specific device discovery protocols, such as 
Bluetooth 's, in a messaging API for the distributed comput- 
ing environment. Wrapping may include framing the device 
discovery protocol with code and/or data (the API) so that 
the protocol can be run by clients and/or services in the 
distributed computing environment that would not otherwise 
be able to run it. When run, the bridging mechanism may 
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allow for a discovery agent that discovers devices by a 
specific device discovery protocol to publish services for 
those devices in a space in the distributed computing envi- 
ronment. The services present an XML message schema 

5 interface to clients in the distributed network environment, 
and are capable of operating the various devices discovered 
by the specific device discovery protocol. Thus, service 
advertisements may be published for the services that oper- 
ate the various devices discovered by the underlying 

10 wrapped device discovery protocols. The advertised services 
thus bridge devices (or services) external to the distributed 
network environment to clients on the distributed network 
environment. 

FIG. 27 illustrates one embodiment of a distributed com- 

15 puting environment with a space 1200. One or more dis- 
covery agents 1204 may participate in an external discovery 
protocol and bridge to the distributed computing environ- 
ment through bridging mechanism 1202. When the wrapped 
device discovery protocols are run, discovery agents 1204 

20 through bridging mechanism 1202 may publish service 
advertisements 1206a- 1206c in space 1200, wherein each 
one of advertisements 1206a-1206c corresponds to a device 
or service discovered by one of discovery protocols 1204 
outside the distributed computing environment. Clients may 

25 then access the external devices using the service advertise- 
ments 1206a-1206c in space 1200 to instantiate services on 
one of the agents 1204 that operates the corresponding 
external device or service. 
Thus, clients of the distributed computing environment 

30 may use discovery agents wrapping device discovery pro- 
tocols to find devices. A service acting as a bridge to these 
devices may be published in a space and advertised, so 
clients of the distributed computing environment may access 
the services provided by the external devices. The advertised 

35 service is a service within the distributed computing envi- 
ronment that is able to invoke a device outside the distrib- 
uted computing environment via another protocol or 
environment, thus bridging the outside device/service to the 
distributed computing environment. A client within the 

40 distributed computing environment "sees" only the adver- 
tised service within the distributed computing environment 
and may not even be aware of the outside device/service. 

In one embodiment, the distributed computing environ- 
ment may provide a version of a space discovery message 

45 protocol, such as the discovery protocol described in the 
Spaces section, that may be mapped to an underlying 
external device discovery protocol, including the wrapped 
device discovery protocols described above. The mapped 
discovery protocol may register itself or be registered with 

so a space, e.g. a default space, by placing an advertisement in 
that space. For each advertised discovery protocol, a sub- 
sequent results space to hold the results of the discovery 
protocol may be provided. 

FIG. 28 illustrates an example of the space discovery 

55 protocol mapped to a Bluetooth discovery service 1220 
according to one embodiment. The Bluetooth discovery 
service 1220 may first register 1230 with the distributed 
computing environment. The Bluetooth discovery service 
1220 may be wrapped in a bridging API, and an advertise - 

60 ment 1225 for the discovery service 1220 may be added 
1232 in space 1224. A client or service may locate the 
discovery service advertisement 1225 on space 1224. When 
the discovery service 1220 is executed (utilizing the API 
wrapper as a bridge between the discovery protocol 1220 

65 and the distributed computing environment 1222), a new 
space 1226 may be created 1234 to store the results of the 
discovery process. The discovery service 1220 may store the 
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results (again through the API wrapper) to discovery results posted in a results space, and the location of the results may 

space 1226 as one or more advertisements, 1227. be returned to the client 1250. Client 1250 may then choose 

Alternatively, results of executing discovery service 1220 to execute service advertisement 1256a, and may send a 

may be stored to space 1224 or other pre-existing spaces in message (in the client 1250's communications protocol) to 

the distributed computing environment. A similar method as 5 bridging agent 1252. Bridging agent 1252 may then send the 

illustrated in FIG. 28 may be used to discover devices and XML request message(s) necessary to execute the service 

other services using other underlying discovery protocols. represented by service advertisement 1256a, and may return 

As mentioned above, there may be devices, external to the the results of the service to client 1250. Methods of handling 

distributed network environment, which do not support the the results of the service other than directly returning the 

message passing model implemented by the distributed 10 results to the client 1250 may be used as described above in 

network environment. These devices may have clients that the section titled Spaces. Bridging agent 1252 thus may act 

may want to use services provided in the distributed com- as a service of the external client 1250 (via the external 

puling environment. The distributed computing environ- client's protocol) and as a client within the distributed 

ment may provide a mechanism to bridge the external clients computing environment to bridge a service within the dis- 

or client devices to the distributed computing environment 15 tributed computing environment to the external client, 

so that the clients on the external devices may access Sometimes, even within the distributed computing 

services in the distributed computing environment. environment, clients and services cannot directly commu- 

Agents may be provided that serve as clients in the nicate with each other, only to a common space. In this case, 

distributed computing environment to bridge external clients the space service will automatically create a service proxy 

to the distributed computing environment, allowing the 20 that bridges client to service. The proxy's main job is to 

external clients to access services published in the distrib- route messages between client and service through the 

uted computing environment. In one embodiment, an agent space. The service proxy may be created dynamically. The 

may have an XML-enabled back end capable of communi- creation mechanism may be dependent upon space imple- 

cating with services in the distributed computing environ- mentation. Refer to FIG. 30 for an illustration of a proxy 

ment using the message passing model, and a proprietary 25 mechanism. A client 554 and a service 556 may not be able 

protocol (e.g. a protocol supported by the external device) to communicate directly within the distributed computing 

on the front end to interface to the external device, and thus environment, e.g., because they support different transport 

to the external client. Thus, a client external to the distrib- or network protocols. However, they both may be able to 

uted computing environment may locate and access services communicate with a space 552 that supports both protocols, 

in the distributed computing environment through the bridg- 30 The space service may create a proxy 550 to bridge the client 

ing agent, and may send requests to the services and receive 554 to the service 556. A common form of proxy is a 

responses from the services, including results data. For browser proxy. A browser proxy (most commonly imple- 

example, an external client may use the bridging agent to run mented as a servlet) may translate conventional Web page 

space discovery in the distributed computing environment, requests into messages. Refer also to the description of space 

look up advertised services, and invoke services in the 35 search services (and proxies therefore) in the Spaces section 

distributed computing environment. herein. 

In one embodiment, the distributed computing environ- In the computer industry, an enterprise may be a 

ment may provide a bridging mechanism for accessing Jini corporation, small business, non-profit institution, govern- 

services from a distributed computing environment client. ment entity, or other kinds of organization. An enterprise 

Since Jini services may require Remote Method Invocation 40 may utilize a enterprise computing environment for con- 

(RMI), and since clients in the distributed computing envi- ducting a portion of its business. The enterprise computing 

ronment may communicate to services using messages such environment may include various enterprise services. Cli- 

as XML messages, a protocol bridging mechanism may be ents in the distributed computing environment may desire to 

provided to enable the access of a Jini Service by a distrib- use services in the enterprise computing environment, 

uted computing environment client. In one embodiment, a 45 The distributed computing environment may provide a 

connector mechanism may be defined that enables the mechanism for bridging clients in the distributed computing 

dynamic advertisement of Jim services in distributed com- environment to enterprise services. In one embodiment of a 

puting environment spaces, and that also may enable the distributed computing environment, a method for bridging 

accessing of a Jini service proxy from clients in the distrib- clients to enterprise services may include a client within the 

uted computing environment. In one embodiment, there may 50 distributed computing environment, a bridge service within 

be Jini services that may not be bridged to the distributed the distributed computing environment, and an enterprise 

computing environment. service within the enterprise environment. The distributed 

FIG. 29 illustrates bridging a client 1250 external to the computing environment bridge service serves as a bridge 
distributed computing environment to a space 1254 in the service between the client and the enterprise service, 
distributed computing environment. Bridging agent 1252 55 The bridge service interacts with the client via XML 
may serve as the go-between between client 1250 and space message passing to gather input parameters necessary to 
1254. Bridging agent 1252 may communicate with client make requests to the enterprise service outside of the dis- 
1250 in a communications protocol understandable by the tributed network environment. For example, the bridge 
client 1250. Bridging agent 1252 may map the client's service may be looked up and instantiated by the client just 
communications protocol into the XML messaging protocol 60 as any other service in the distributed computing environ- 
necessary to communicate with space 1254 perform the ment. The bridge service then may interact with the enter- 
facilities provided by space 1254. Bridging agent 1252, at prise service to run the enterprise service. This interaction 
client 1250's request, may locate and run services on space may use an interprocess communications architecture that 
1254. For example, client 1250 may request a list of all the enterprise service can understand. As an example, if an 
services of a particular type from space 1254. Bridging agent 65 enterprise service is implemented with Enterprise JavaBeans 
1252 may locate service advertisements 1256a-c and return (EJB), a bridge service may communicate with the enter- 
the results to client 1250. Alternatively, the results may be prise service using EJB. The bridge service may then receive 
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results from the enterprise service and may return the results 
directly to the client (in XML messages) or may place the 
results in a space in the distributed network environment 
(e.g. a results space). To the client, the bridge service 
appears to be the only service (the enterprise service is 
hidden to the client), so the client does not have to support 
the architecture of the enterprise service. Multiple distrib- 
uted network environment clients may use the same bridge 
service (each using a unique gate pair) to interact with the 
enterprise service. 
Client Displays 

There are several methods in which results from a service 
run by a client may be displayed in a distributed computing 
environment. Devices that may display results may include, 
but are not limited to: CRTs on computers; LCDs on laptops, 
notebooks displays, etc; printers; speakers; and any other 
device capable of displaying results of the service in visual, 
audio, or other perceptible format. The methods for display- 
ing results may include, but are not limited to: 

The service may return results to a client directly or by 
reference, and the client may handle the display of the 
results. 

The service may return results to a client directly or by 
reference, and the client may pass the results to a 
display service directly or by reference, and the display 
service may display the results. 

The service may directly handle the displaying of the 
results. 

The service may pass the results to a display service 
directly or by reference, and the display service may 
display the results. 

In the last method of displaying results, the display 
service may be specified by the client. For example, there 
may be a display service on or associated with the device on 
which the client resides that the client wishes to use to 
display the results of the service, When the client runs the 
service, the client may send a message to the service 
specifying the service advertisement of the client's display 
service. The service may then build a gate that allows it to 
send messages to the client's display service. Thus, when 
displaying results, the service invoked by the client becomes 
a client of the client's display service and send its results 
(directly or by reference) for display to that display service. 
More detail on the client -service relationship, gates, and 
messaging is included in other sections of this document. 

FIG. 31 illustrates one embodiment of a client 1300 with 
associated display 1302 and display service 1304 according 
to one embodiment. 

Conventional application models are typically based on 
predetermined, largely static user interface and/or data char- 
acteristics. Changes to conventional applications may 
require code modification and recompilation. The mecha- 
nisms described for advertising services and for specifying 
XML message schemas for communicating with services in 
the distributed computing environment may be used to 
provide a mechanism for applications (clients, services, etc) 
to describe dynamic display objects. Using the dynamic 
display objects, application behavior may be altered without 
having to download new code, recompile, or relink the 
application. 

FIGS. 32A and 32B illustrate examples of using schemas 
of dynamic display objects according to one embodiment. 

Display schemas may be provided for displaying the same 
results in different formats, for extracting portions of the 
results for display, and for displaying the results on different 
display devices. 
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String Management 

String handling in conventional systems is generally not 
very efficient, especially for variable sized strings, and may 
be wasteful of memory space, e.g. as the string is copied 

5 and/or moved in memory. This inefficiency in string han- 
dling may be particularly problematic in small memory 
footprint systems such as embedded systems. Thus, a more 
efficient method of handling strings in programs executing 
within small footprint systems such as embedded systems is 

io desirable. 

FIG. 33A illustrates a typical string representation in the 
C programming language. 

FIG. 33B illustrates an example of the results of the 
strncpy( ) function on string 1452, when strncpy( ) is called 

is with the following parameters: 
strncpy(string2, stringl+3, 5); 
where string2 is character pointer 1454 pointing to the first 
byte after the terminating character of string 1452, stringl+3 
is character pointer 1450 incremented by 3 bytes, and 5 is the 

20 number of characters (bytes) to be copied from the source 
location stringl+3 to string2. 

FIG. 33 C illustrates an efficient method for representing 
and managing strings in general, and in small footprint 
systems such as embedded systems in particular. 

25 The string handling structures and methods as described 
in FIG. 33C may be used, along with the hierarchical 
structure of XML documents, to provide more efficient 
handling of XML text (such as XML messages) in systems 
with small memory footprints such as embedded systems, 

30 The hierarchical structure of XML documents may allow 
them to be processed in a recursive fashion with succes- 
sively smaller portions of the document processed at each 
level of recursion. References to various portions are 
recorded and processed recursively. String structures as 

35 described in regard to FIG. 33C may be used to record the 
various portions. In this manner, the content of specific XML 
tags, in one embodiment the smallest unit of the XML 
document processed recursively, may be determined effi- 
ciently. Documents with repeated tags in the same scope 

40 may also be handled efficiently, as tags within a given scope 
may be enumerated and processed efficiently. 

Using the string structures with the recursive processing 
allows the processing to be done without creating copies of 
the subsections for processing. Copying of subsections may 

45 be particularly costly in recursive processing, because as the 
recursion goes deeper, more and more copies of the same 
data are made. Using the string structures, only the string 
structure containing the pointers to the first and last bytes in 
the subsection needs to be created and passed down to the 

50 next level. Other operations, such as determining the length 
of a subsection, may be performed efficiently using the 
address information stored in the string structures. Also, by 
using the string structures, terminating characters such as 
those used to terminate C strings are not necessary, con- 

55 serving memory in small footprint devices such as embed- 
ded devices. 

XML Representation of Objects 

As previously mentioned, Jini RMI may not be practical 
for some clients, such as thin clients with minimal memory 

60 footprints and minimal bandwidth. The serialization associ- 
ated with the Jini RMI is slow, big, requires the JVM 
reflection API, and is a Java specific object representation. 
Java deserialization is also slow, big and requires a 
serialized-object parser. Even Java based thin clients may 

65 not be able to accept huge Java objects (along with needed 
classes) being returned (necessarily) across the network to 
the client, as required in Jini. 
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A more scalable distributed computing mechanism may the object graph, including Java object 1510. In one 

be provided by embodiments of a distributed computing embodiment, the objects in the object graph may be stored 

environment. A distributed computing environment may recursively in the XML data stream 1514, and thus a 

include an API layer for facilitating distributed computing. recursive decompilation process may be used. 

The API layer provides send message and receive message 5 When service 1502 needs to send a Java object to client 

capabilities between clients and services. This messaging 1500, a substantially similar process may be used. Java 

API may provide an interface for simple messages in a object 1520 may be passed to a Java object compilation 

representation data or meta-data format, such as in the process 1512 to be compiled to produce an XML represen- 

eXtensible Mark-up Language (XML). Note that while tation of the object graph. The XML representation of the 

embodiments are described herein employing XML, other 10 object graph may be passed as an XML data stream 1522 to 

meta-data type languages or formats may be used in alter- gate 1506. Gate 1506 may then package the XML data 

nate embodiments. In some embodiments, the API layer may stream 1522 in a message 1524 and send the message 1524 

also provide an interface for messages to communicate to gate 1504 of client 1500. Gate 1504 may extract the XML 

between objects or to pass objects, such as Java objects. data stream 1522 from XML message 1524 and send the 

Objects accessible through API layer 102 are represented by 15 XML data stream 1522 to an XML data stream decompila- 

a representation data format, such as XML. Thus, an XML tion process 1518 to be decompiled to produce the object(s) 

representation of an object may be manipulated, as opposed comprising the object graph, including Java object 1520, 

to the object itself. In another embodiment, the gates may be responsible for 

The API layer may sit on top of a messaging layer. The the compilation and decompilation of Java objects. In this 

messaging layer may be based on a representation data 20 embodiment, Java object 1510 may be passed to gate 1504. 

format, such as XML. In one embodiment, XML messages Gate 1504 may then pass object 1510 to a Java object 

are generated by the messaging layer according to calls to compilation process 1512 to be compiled to produce an 

the API layer. The messaging layer may provide defined XML representation of the object graph in an XML data 

static messages that may be sent between clients and ser- stream 1514. Gate 1504 may then package the XML data 

vices. Messaging layer may also provide for dynamically 25 stream 1514 in a message 1516 and send the message 1516 

generated messages. In one embodiment, an object, such as to gate 1506 of service 1502. Gate 1506 may extract the 

a Java object, may be dynamically converted (compiled) XML data stream 1514 from XML message 1516 and send 

into an XML representation. The object may include code the XML data stream 1514 to an XML data stream decom- 

and/or data portions. The object's code and/or data portions pilation process 1518 to be decompiled to produce the 

may be compiled into code and data segments identified by 30 object(s) comprising the object graph, including Java object 

XML tags in the XML representation. The messaging layer 1510. Sending a Java object from service 1502 to client 1500 

may then send the XML object representation as a message. may be substantially similar. 

Conversely, the messaging layer may receive an XML In one embodiment, object compilation process 1512 and 

representation of an object. The object may then be recon- object decompilation process 1518 may both exist on the 

stituted (decompiled) from that message. The reconstitution 35 client 1500 and the service 1502, and may be programmed 

may examine the XML representation for tags identifying to perform compilation and decompilation substantially 

code and/or data segments of the XML representation, and similarly on the two devices, thus ensuring the object(s) 

use information stored in the tags to identify and decompile output on one end are substantially identical to the object(s) 

the code and/or data portions of the object. input on the other end. In one embodiment, XML schemas 

Creating and Sending an XML Representation of an Object 40 including descriptions of Java objects may be used on both 

FIG. 34 illustrates a process of moving Java objects the client and/or the service in the compilation and decom- 

between a client 1500 and a service 1502 according to one pilation processes. In one embodiment, XML schema(s) to 

embodiment of the invention. Service 1502 may be any be used in the compilation and decompilation of Java objects 

service supported in the distributed computing environment, may be passed by the service to the client in the service 

including space services. Client 1500 employs a gate 1504, 45 advertisement. 

which may have been created using an XML schema XML provides a language- and platform-independent 

received from a service advertisement for service 1502, to object representation format. Thus, the process as illustrated 

communicate with a corresponding gate 1506 for service in FIG. 34 where an object is compiled into an XML 

1502. At some point, client 1500 may need to send Java representation of the object and decompiled to reproduce the 

object 1510 to service 1502. Java object 1510 may reference 50 object may not be limited to moving Java objects, but in 

other objects, which may reference other objects, and so on. some embodiments may be applied to moving objects of 

Java object 1510 and its referenced objects, the objects they other types between entities in a network, 

reference, and so on, may be referred to as an object graph. JVM Compilation/Decompilation API 

Java object 1510 may be passed to a Java object compi- FIGS. 35a and 35ft are data flow diagrams illustrating 
la tion process 1512 to be compiled to produce an XML 55 embodiments where a virtual machine (e.g. JVM) includes 
representation of the object graph. The XML representation extensions for compiling objects (e.g. Java Objects) into 
of the object graph may be passed as an XML data stream XML representations of the objects, and for decompiling 
1514 to gate 1504. The XML data stream 1514 may include XML representations of (Java) objects into (Java) objects, 
an XML representation of all the objects in the object graph. The JVM may supply an Applications Programming Inter- 
In one embodiment, the objects in the object graph may be 60 face (API) to the compilation/decompilation extensions. The 
stored recursively in the XML data stream 1514. client 1500 and service 1502 may be executing within 

Gate 1504 may then package the XML data stream 1514 JVMs. The JVMs may be on the same device or on different 

in a message 1516 and send the message 1516 to gate 1506 devices. 

of service 1502. Gate 1506 may extract the XMLdata stream In both FIG. 35a and FIG. 35ft, the JVM XML compiler/ 

1514 from XML message 1516 and send the XML data 65 decompiler API 1530 may accept a Java object 1510 as 

stream 1514 to an XML data stream decompilation process input, and output an XML representation of the object 1510 

1518 to be decompiled to produce the object(s) comprising and all its referenced , objects (the object graph of object 
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1510) in an XML data stream 1514. In addition, the JVM and in parsing the XML representation to produce the object 

XML compiler/decompiler API 1530 may accept an XML graph. Thus, the compilation/decompilation functions may 

data stream 1522, which includes an XML representation of not have to duplicate functionality that is provided by the 

object 1520 and all its referenced objects (the object graph JVM, as do object sending methods using reflection and 

of object 1520), and output Java object 1520 (and all the 5 serialization. This may allow the code footprint of the 

objects in its object graph). compilation/decompilation functions to be smaller than that 

FIG. 35a illustrates one embodiment where, when send- of object sending methods using reflection and serialization, 

ing Java object 1510, the JVM XML compiler/decompiler Also, an object may be complied or decompiled by a single 

API 1530 is called by the client. The client 1510 passes Java call to the JVM XML compiler/decompiler API. 

object 1510 to the API 1530, which compiles the object to 10 In addition, integrating the compilation/decompilation of 

produce its XML representation, stores the XML represen- objects with the JVM may allow the compilation and 

tation in XML data stream 1514, and outputs XML data decompilation of objects to be performed faster than metb- 

stream 1514. XML data stream 1514 may then be passed to ods using reflection and serialization because, in the object 

gate 1504 by the client. Gate 1504 may then package the traversal model implemented with reflection and 

XML data stream 1514 in an XML message 1516 and send 15 serialization, the code outside the JVM does not know the 

message 1516 to service 1502. structure or graph of the Java object, and thus must traverse 

Upon receiving XML message 1524 from service 1502, the object graph, pulling it apart, and ultimately must 

gate 1522 may extract XML data stream 1522 from message repeatedly call upon the JVM to do the compilation (and the 

1524 and pass data stream 1522 to client 1500. Client 1500 reverse process for decompilation). This process may be 

may then call the JVM XML compiler/decompiler API 20 slowed by the necessity of making repeated calls to the 

1530, passing API 1530 the XML data stream 1522. The API JVM, outside the code. Having the compilation and decom- 

1530 may then decompile the XML data stream 1522 to pilation functionality integrated with the JVM, as described 

produce Java object 1520 and other objects in its object herein, avoids having to make repeated calls from code 

graph, returning the objects to client 1500. outside the JVM to the JVM. In one embodiment, an object 

FIG. 35b illustrates another embodiment where, when 25 may be complied or decompiled by a single call to the JVM 

sending Java object 1510, the JVM XML compiler/ XML compiler/decompiler API. 

decompiler API 1530 is called by the gate. The client 1510 In one embodiment, the compilation/decompilation func- 

passes Java object 1510 to gate 1504. Gate 1504 then passes tionality may be implemented as a service in the distributed 

object 1510 to API 1530, which compiles the object to computing environment. The service may publish a service 

produce its XML representation, stores the XML represen- 30 advertisement in a space. A process in the distributed com- 

tation in XML data stream 1514, and outputs XML data puting environment may use a search or discovery service to 

stream 1514. Gate 1504 may then package the XML data locate the compilation/decompilation service. The process (a 

stream 1514 in an XML message 1516 and send message client of the service) may then use the service by passing 

1516 to service 1502. Java objects to be compiled into XML representations and/or 

Upon receiving XML message 1524 from service 1502, 35 XML representations to be decompiled into Java objects to 

gate 1522 may extract XML data stream 1522 from message the service. 

1524 and pass data stream 1522 to the JVM XML compiler/ Java objects may include code (the object's methods) and 

decompiler API 1530. The API 1530 may then decompile' data. An object's code may be non-transient; the code does 

the XML data stream 1522 to produce Java object 1520 and not change once the object is created. An object's data, 

other objects in its object graph. The gate may then send 40 however, may be transient. Two objects created from the 

Java object 1520 and the other objects to client 1500. same Java class may include identical code, but the data in 

In one embodiment, the JVM XML compiler and decom- the two objects may be different. In one embodiment, the 

piler may be implemented as integrated functions of the compilation function may compile a Java object's data into 

JVM. In another embodiment, the XML compiler and an XML representation of the object, but may not include the 

decompiler may be embodied in API method invocations in 45 object's actual code in the XML representation. In one 

standard extensions to the JVM; thus, the core JVM does not embodiment, information about the object may be included 

have to be modified. The JVM may supply the JVM XML in the compiled XML representation to indicate to the 

compiler/decompiler API 1530 to processes (clients and/or receiver how to recreate the code for the object. The XML 

services) executing within the JVM to allow the processes to representation may then be stored in an XML data stream 

access the Java object compilation/decompilation function- 50 and sent (e.g., in a message) to a receiving process (client or 

ality provided by the JVM. In one embodiment, for a process service). The receiving process may then pass the XML data 

to utilize the object compilation/decompilation, the JVM stream to the decompilation function. The decompilation 

within which the process is executing must have the JVM function may then decompile the XML data stream to 

XML compiler/decompiler functionality and API 1530. produce the Java object including its data. In one 

Methods using reflection and serialization to transform 55 embodiment, the code for the object may be reproduced by 

and send objects are typically implemented in applications the decompilation function using information about the 

separate from the JVM. The application must repeatedly object in the XML representation, as the code for an object 

access the JVM to pick apart an object one field at a time as may be statically defined and the JVM receiving the object 

the transitive closure of the object is dynamically analyzed. may be able to reproduce the code (if necessary) using its 

This tends to be a slow and cumbersome process, while also 60 knowledge of the object. 

requiring large amounts of application and JVM code. In one embodiment, the XML representation of the object 

Implementing the Java object compilation/decompilation produced by the compilation function may include the Java 

functionality within the JVM is advantageous because the object's data and information about the Java object. The 

JVM already understands the concept of, and contents of, an information may include class information for the Java 

object graph. Thus, the compilation/decompilation functions 65 object. An object signature may be included in the informa- 

may leverage the knowledge (and reuse code) of the JVM in lion and may be used to identify the object's class, etc. The 

parsing the object graph to produce the XML representation, decompilation function may recreate the code for the Java 
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object using the information about the Java object and may 
decompile the data from the XML data stream into the Java 
object. Thus, a complete object including its code and data 
may be reproduced on the JVM executing the receiving 
client or service from the decompiled data and the informa- 
tion describing the object. In one embodiment, the informa- 
tion describing the object may be stored in one or more XML 
tags. In one embodiment, the client or service receiving the 
XML data stream may include an XML schema that 
describes the object, and the XML schema may be used to 
reconstruct the Java object from the decompiled data and 
from the information about the Java object. The decompi- 
lation process may proceed recursively through the object 
graph, reconstructing the objects referenced by the object by 
decompiling the referenced objects' data from the XML data 
stream and recreating the referenced objects' code from 
information about the referenced objects in the XML data 
stream. 

In one embodiment, the XML representation of the object 
produced by the compilation function may include the 
object's data and information that identifies the code of an 
object. In one embodiment, the information identifying the 
code of the object may be stored in one or more XML tags 
in the XML data stream. When received, the decompilation 
function may recreate the code for the Java object using the 
information about the code from the XML data stream and 
decompile the data for the object from the XML data stream. 
Thus, a complete object including its code and data may be 
reproduced on the JVM executing the receiving client or 
service from the decompiled data and the information 
describing the code of the object. 

Several scenarios of using XML representations of 
objects to transfer objects between entities (typically clients 
and services) in a distributed computing environment are 
included for clarification. These scenarios are exemplary 
and are not intended to be limiting. 

In a first scenario, a service may use the XML compiler/ 
decompiler to compile a Java object into an XML represen- 
tation of the object and send the XML representation to a 
client. The client may the use the XML compiler/decompiler 
to decompile the XML representation and perform opera- 
tions on the data within the object, and later may use the 
XML compiler/decompiler to compile the object into an 
XML representation of the object and return the XML 
representation of the object to the service. 

In a second scenario, a service may use the XML 
compiler/decompiler to compile a Java object into an XML 
representation of the object and send the XML representa- 
tion to a client. The client may then send the XML repre- 
sentation to another service, which may use the XML 
compiler/decompiler to decompile the XML representation 
to reproduce the object, perform operations on the object at 
the request of the client (possibly modifying the data), use 
the XML compiler/decompiler to recompile the modified 
object into its XML representation, and send the XML 
representation of the object to the client. 

In a third scenario, a service may use the XML compiler/ 
decompiler to compile a Java object into an XML represen- 
tation of the object and send the XML representation to an 
object repository or store space. The service may then send 
a message to a client informing the client of the location of 
the XML representation. The message may include a Uni- 
versal Resource Identifier (URI) for the XML representa- 
tion. The client may then retrieve the XML representation of 
the object from the store space, and may use the XML 
compiler/decompiler . to decompile the representation to 
reproduce the object. Alternatively, the client may send the 
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location of the XML representation of the object to another 
service, along with a request for operations to be performed 
on the object. The other service may then retrieve the XML 
representation from the store space, use the XML compiler/ 
5 decompiler to decompile the XML representation to repro- 
duce the object, and perform the requested operations on the 
object. 

In a fourth scenario, a process (could be a client or 
service) may locate an object repository or store space in the 

10 distributed computing environment by searching for and 
finding a service advertisement for the store space. The 
process may, during execution, create or obtain a plurality of 
Java objects. The process may use the XML compiler/ 
decompiler to compile one or more of the objects into XML 

is representations of the objects, and may send, as a client of 
the store space service, the XML representations of the 
objects to the store space to be stored for possible later 
access, or for access by other processes. 
Security Issues in the Decompilation of XML Representa- 

20 tions of Objects 

Spaces, as described herein, may serve as a file system in 
the distributed computing environment. Security may be 
provided for files in the system in the form of access rights. 
Access rights may be checked each time a file is accessed 

25 (opened, read, or written to). Thus, a method for providing 
file access security in the distributed computing environment 
may be desirable. This method may also be applied to the 
XML representations of Java objects that may be stored in 
spaces and transmitted between clients and services in the 

30 distributed computing environment. 

In one embodiment, a user of a client on a device in the 
distributed computing environment may be identified and 
authenticated when first accessing the client. In one 
embodiment, the user may supply a physical identification 

35 such as a smart card for identification and authorization. In 
another embodiment, a challenge-response mechanism 
(such as user ID and password) may be used for identifica- 
tion and authorization. Yet another embodiment may use 
electronic identification such as a digital signature for iden- 

40 tification and authorization. Any other method of identifi- 
cation and authorization may be used. 

Once identified and authorized, the user may then perform 
various operations on the client, including accessing one or 
more services in the distributed computing environment. 

45 During these operations, as described above, one or more 
objects may be created or acquired elsewhere. The objects 
may be modified and may be compiled into XML represen- 
tations of the objects and stored locally by the client or sent 
to a space service for (transitive or persistent) store. Some of 

50 the objects may be received from services (store services or 
other services) in the form of XML representations of the 
objects, which may be decompiled by the XML compiler/ 
decompiler to recreate the objects on the client. 

In one embodiment, during the decompilation of the XML 

55 representation of objects, each XML message may be 
checked to verify that the user has access rights to the object. 
If the user does not have the proper access rights, the XML 
compiler/decompiler may not decompile the object for the 
user. In one embodiment, a security exception may be 

60 thrown by the XML compiler/decompiler. In one 
embodiment, the user may be informed of the access vio- 
lation. 

Access right information, such as the creator and access 
levels allowed (creator-only access, read only, read/write, 
65 delete, copy, etc.) for the object may be embedded in the 
XML messages) containing the XML representation of the 
object. Access authorization may be determined during the 



05/14/2004, EAST version: 1.4.1 



US 6,643, 

87 

identification and authorization of the user. For example, the 
object may allow "read only" access for most users, and 
"read/write" access for the creator of the object. If the user 
tries to access an object using read/write access rights, and 
the object was not created by the user, the decompilation 5 
process may detect this as an access violation, and may 
disallow the access and notify the user. 

In one embodiment, when the user is done using the 
client, the user may log off or otherwise signal the user is 
finished with the client (e.g. remove a smart card). Objects 10 
created on the client by decompilation may be automatically 
deleted when the client detects that the user is finished. This 
may prohibit future users from intentionally or accidentally 
accessing the user's objects. In one embodiment, all objects 
created by decompilation may be deleted upon detecting that 15 
the user is finished. In another embodiment, a method may 
be provided to store at least some of the objects created on 
the client persistently (e.g. with access rights information), 
so that the client may later access the objects, or provide the 
objects to other users for access. 20 

In one embodiment, the user may have a "smart card" or 
other physical device to gain access to the client. The user 
may insert the smart card into the client device to begin the 
session. When the client is finished, the client may remove 
the smart card. The client may detect the removal of the 25 
smart card, and thus detect that the client is finished, and 
may then proceed to delete objects created by decompilation 
of XML representations. 
XML-based Object Repositories 

In the distributed computing environment, processes 30 
(services and/or clients) may desire transient and/or persis- 
tent storage of objects such as XML schemas, service 
advertisements, results generated by services, XML repre- 
sentations of Java objects and/or objects implemented in 
other languages, etc. Existing object storage technologies 35 
tend to be language and/or operating system specific. These 
storage systems also tend to be too complicated to be used 
with small footprint systems such as embedded systems. 

JavaSpaces in Jini is an existing object repository mecha- 
nism. A JavaSpace may be only capable of storing Java 40 
objects and may be too large to be implemented in small 
devices with limited amounts of memory. Each object in a 
JavaSpace may be serialized as previously described, and 
thus has the same limitations as previously described for the 
reflection and serialization techniques. 45 

A store mechanism may be provided for the distributed 
computing environment that may be heterogeneous (not 
language or operating system dependent), that may scale 
from small to large devices, and that may provide transient 
or persistent storage of objects. In one embodiment, the store 50 
mechanism in the distributed computing environment may 
be implemented as an Internet Web page or set of pages 
defined in the XML markup language. XML provides a 
language- and platform-independent object representation 
format enabling Java and non-Java software to store and 55 
retrieve language-independent objects. Since the store 
mechanism is on the Web, devices of all types and sizes 
(small to large) may access the store mechanisms. Web 
browsers may be used to view the store mechanism imple- 
mented as Web pages. Web search engines may be used to 60 
search for contents in the store mechanism implemented as 
Web pages. Internet administration mechanisms (existing 
and future) and XML tools may be used to administer the 
XML-based store mechanisms. 

In one embodiment, the store mechanisms may be used to 65 
store objects created, represented or encapsulated in XML. 
Examples of objects that may be stored in the store mecha- 
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nisms may include, but are not limited to: XML schemas, 
XML representations of objects (for example, Java objects 
compiled into XML representations as described above), 
service advertisements, and service results (data) encapsu- 
lated in XML. In one embodiment, to prevent unauthorized 
access of an XML object, an authorization credential such as 
a digital signature or certificate may be included with the 
XML object, and a client wishing to access the XML object 
may be required to have the proper authorization credential 
to access the XML object. In one embodiment, the store 
mechanism may be a space as described in the Spaces 
section herein. 

Store mechanisms may be services in the distributed 
computing environment. A store mechanism implemented as 
a service may be referred to as a "store service". A store 
service may publish an advertisement in a space. The space 
itself is an example of a store service. Some store services 
may be transient. For example, a space service that stores 
service advertisements may be a transient store. Other store 
services may be persistent. For example, a store service that 
stores results from services may be a persistent store. 

FIG. 36 illustrates a client 1604 and a service A 1606 
accessing store mechanisms 1600 and 1602 in the distrib- 
uted computing environment according to one embodiment. 
This illustration is intended to be exemplary and is not 
intended to be limiting to the scope of this invention. In one 
embodiment, store mechanisms 1600 and 1602 may each be 
an Internet Web page or set of Web pages defined in XML 
and accessible by a Web browser and other Internet tools. 
Store mechanism 1600 is a transient store capable of storing 
objects implemented using XML. Store mechanism 1602 is 
a persistent store also capable of storing objects imple- 
mented using XML. Service A 1606 may publish an XML 
service advertisement 1608 in transient store 1600. Persis- 
tent store may also publish an XML service advertisement in 
transient store 1600 (or on another transient store in the 
distributed computing environment). At some point, client 
1604 may require functionality provided by Service A 1606. 
Client 1604 may use a discovery and/or lookup service to 
locate service advertisement 1608. Client 1604 may then 
construct a message gate, as described herein, and begin 
communications with Service A 1606. Client 1604 may send 
one or more XML request messages to Service A 1606. 
Service A 1606 may perform one or more functions in 
response to the one or more request messages. One or more 
of the functions performed by Service A 1606 may produce 
results to be provided to client 1604. 

For transient results 1610, Service A 1606 may encapsu- 
late the results in an XML advertisement 1612 and publish 
the advertisement 1612 in transient store 1600 (or on another 
transient store in the distributed computing environment). 
Service A 1606 may then notify client 1604 that the results 
1610 are stored in advertisement 1612 on transient store 
1600, or client 1604 may be notified by other mechanisms 
as described herein. Client 1604 may then retrieve transient 
results 1610 from advertisement 1612, The advertisement 
1612 may include an XML schema describing the 
formatting, contents, type, etc. of the transient results 1610. 
The results may be encapsulated in XML, For example, 
XML tags may be used to describe portions of the data: 

<XML taglxdatal> 

<XML tag2xdata2> 

For persistent results 1618, Service A 1606 may use a 
service or other mechanism as described herein to locate 
XML service advertisement 1616 for persistent store 1602, 
and thus locate persistent store 1602 for storing persistent 
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results. Alternatively, client 1604 may have previously 
located persistent store 1602 by locating its service adver- 
tisement 1616, and then may send a Universal Resource 
Identifier (URI) for a storage location for persistent results 
1618 to Service A in an XML message. In one embodiment, 
persistent results 1618 may be stored in an Internet Web 
page or set of Web pages defined in XML and accessible by 
a Web browser. Service A 1606 may then store persistent 
results 1618 in persistent store 1602. Service A 1606 may 
then publish an XML advertisement 1616 for the persistent 
results 1618 in transient store 1600 (or on another transient 
store in the distributed computing environment) and return 
the location of the advertisement 1616 to client 1604. The 
advertisement 1616 may include an XML schema describing 
the formatting, contents, type, etc. of the persistent results 
1618. The results may be encapsulated in XML as previ- 
ously described. The advertisement may also include the 
URI of the persistent results 1618. The client 1604 may then 
retrieve the advertisement 1616 and use it to locate and 
retrieve persistent results 1618. Alternatively, Service A 
1606 may not publish an advertisement for persistent results 
1618, but instead may return a URI for the persistent results 
1618 to client 1604 so client 1604 may access the results 
without looking up an advertisement. Note in some 
embodiments, the various advertisements shown in transient 
store 1600 may each be stored in different transient stores or 
spaces. 

Thus, store mechanisms may be implemented as XML- 
based Internet Web pages in the distributed computing 
environment. These store mechanisms may be implemented 
on a variety of devices in the environment, and may provide 
service advertisements to allow clients (which may be other 
services) to locate and use the store mechanisms. Existing 
and future Web and XML tools may be used to manage the 
store mechanisms. The store mechanisms may store objects 
of various types implemented or encapsulated in XML. 
Clients on devices of substantially any size, from small 
footprint devices to supercomputers, may access the store 
mechanisms to store and retrieve the various objects on the 
Internet. The clients may be Java or non-Java applications, 
as XML provides a language-independent storage format. 
The transient or persistent object repositories may provide 
for a file system in the distributed computing environment 
and may include access checks and other security mecha- 
nism as described herein. 

Dynamically Converting an XML Document into a Java 
Object 

In one embodiment, the distributed computing environ- 
ment may provide a mechanism to convert and represent an 
object class instance into an XML document. In order to 
send representation of a class instance to another service, the 
object may be converted and represented as a XML docu- 
ment. In one embodiment, when receiving an XML 
document, a program may instantiate a class instance cor- 
responding to the object represented by the document. In one 
embodiment, the objects may be Java objects, and the 
program may be a Java program. 
XML-Based Process Migration 

The distributed computing environment may enable the 
distribution and management of distributed applications. For 
example, the distributed computing environment may 
include mobile clients that are dockable with stations that 
provide monitors, printers, keyboards, and various other 
input/output devices that are typically not provided on 
mobile devices such as PDAs, cell phones, etc. These mobile 
clients may run one or more applications, and may migrate 
from one station to another in the distributed computing 
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environment. Thus, one embodiment of the distributed com- 
puting environment may provide a method for migrating an 
executing application (process) with its entire current state 
from a mobile client on one node to the same mobile client 

5 or another mobile client at another node within the distrib- 
uted computing environment. 

FIG. 37 illustrates process migration using an XML 
representation of the state of a process according to one 
embodiment. Process A 1636 a may be executing on node 

10 1630. Process A 1636 a may be a client or service. At some 
point during the execution of Process A 1636a, the state of 
execution of Process A 1636a may be captured and stored in 
an XML-encapsulated state of Process A 1638. The execu- 
tion of Process A 1636a on node 1630 may then be stopped. 

15 Later, node 1632 may locate the XML-encapsulated state of 
Process A 1638 and use it to resume Process A 1636b on the 
node 1632. Resuming Process A may include using the 
stored state 1638 to resume thread execution, recalculate 
transient variables, re-establish leased resources, and per- 

20 form any other functions necessary to resume execution as 
recorded in the stored XML state of the process 1638. 
Applications 

Technologies exist that allow a user to access network 
data from remote locations, making the remote data appear 

25 as local data to the user, provided the user has access to a 
browser. However, such technologies do not provide an 
automatic infrastructure to query networks near a client 
device's location. A mechanism for discovering information 
about networks and services near a client device may be 

30 desirable. For example, such a mechanism may be used to 
locate information about restaurants, weather, maps, traffic, 
movie information, etc within a certain distance (radius) of 
the client device, and to display desired information on the 
client device. An example of using this mechanism may be 

35 a cell phone that can be used to automatically locate services 
in a local environment, for example, in a movie theater to 
display the titles and show times of current features in the 
movie theater or in a restaurant to view menu selections and 
prices. In the distributed computing environment as 

40 described herein, such a mechanism may be used to discover 
spaces including local information and/or services proxi- 
mate to the client device. The mechanism may also be 
applied in other distributed computing environments, for 
example, the Jini system from Sun Microsystems, Inc. 

45 In one embodiment, a mobile client device may include 
Global Positioning System (GPS) capability and wireless 
connection technology. Local distributed computing net- 
works may be provided. For example, a city may provide a 
citywide distributed computing environment. Another 

50 example may be a shopping mall with a local distributed 
computing environment. A local distributed computing net- 
work may include a discovery mechanism to allow client 
devices to connect to the distributed computing environment 
and to discover services and data in the local environment. 

55 For example, one or more devices in the environment may 
include wireless connection technology to allow mobile 
client devices to connect to the network and to access the 
discovery mechanism via the XML messaging system as 
described previously. A local distributed computing envi- 

60 ronment may include one or more spaces with advertise- 
ments for services and/or data to be made available to 
mobile clients. For example, a citywide distributed comput- 
ing environment may include spaces that represent entities 
such as malls, movie theaters, local news, local weather, 

65 traffic, etc. A space may include individual service and/or 
data advertisements for accessing services of and informa- 
tion about the entity the space represents. The discovery 
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mechanism may include a GPS location or locations of the 
local distributed computing environment, entities repre- 
sented by space services within the environment, and/or the . 
various services advertised in the spaces in the environment. 

In one embodiment, wired connections may be provided 5 
to a local distributed computing network. In this 
environment, a user with a mobile client device may "plug 
in" directly to the network using a wired connection "dock- 
ing station". Examples of wired connections include, but are 
not limited to: Universal Serial Bus (USB), Fire Wire, and 10 
twisted-pair Internet. In one embodiment, a docking station 
may also provide input/output capabilities such as a 
keyboard, mouse, and display for the mobile client device. 
In this embodiment, the location of the mobile client device 
may be provided to the lookup or discovery mechanism by is 
the docking station. 

In one embodiment, a mobile client device may connect 
to a distributed computing network. As the user of the 
mobile client device navigates within wireless communica- 
tions range of the distributed computing network, the mobile 20 
client device may constantly, or at various intervals, provide 
a location vector as input to the local lookup or discovery 
mechanism. The mobile client device may obtain the loca- 
tion vector from a GPS system built into or associated with 
the mobile client. In one embodiment, the client may send its 25 
location information (e.g. via XML messaging) to a local 
service discovery mechanism, such as one of the space 
location mechanisms described herein. For example, the 
client may run the space discovery protocol specifying 
discovery for spaces offering services within a certain range 30 
of the clients location, or the client may instantiate a space 
search service to search for spaces advertising services 
provided for the client's vicinity. 

As the mobile client device moves into a specified range 
of a space within the distributed computing environment, the 35 
services and/or data stored in the space may be made 
available to the mobile client device. In embodiments where 
the client device regularly provides its location to a discov- 
ery mechanism, local services and/or data may automati- 
cally be made available to the client's user. In one 40 
embodiment, the specified range of a space may be deter- 
mined by the user of the mobile client device. For example, 
the user may choose to display all restaurants within one 
mile of a current location. Alternatively, the range may be 
specified in the configuration of the local distributed com- 45 
puting network. For example, a citywide distributed com- 
puting network may be configured to provide its services to 
all users within three miles of the city limits. In one 
embodiment, visual indicators, for example icons, represent- 
ing the various services and/or data offered by the space may 50 
be displayed on the mobile client device. The client may 
then access one or more of the displayed services and/or 
data. In one embodiment, information from two or more 
spaces may be displayed simultaneously on the mobile client 
device. In one embodiment, the user may select what 55 
services and/or data are to be detected. For example, in a 
shopping mall, a user with a mobile client device may 
choose to display all shoe stores in the mall. 

In one embodiment, executable code and/or data used in 
the execution of the code may be downloaded to the mobile 60 
client device to allow the user to execute an application 
provided by a service in the space. For example, moviegoers 
with mobile client devices may download interactive movie 
reviews from services in a space for the movie theater, and 
may thus perform real-time feedback about the movie they 65 
are watching. In one embodiment, an XML object 
compilation/decompilation mechanism, e.g. as described 
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elsewhere herein, may be used to compile the code and/or 
data to produce XML representations of the code and/or 
data, and to decompile the XML representations to repro- 
duce the code and/or data on the mobile client device. In one 
embodiment, an executable version of a process may pre- 
viously exist on the mobile client device, and a stored state 
of the process may be downloaded to the mobile client 
device to allow the user to execute the process using the 
stored state. In one embodiment, an executable version of a 
process may previously exist on the mobile client device, 
and data for the process may be downloaded to the mobile 
client device. For example, data may be downloaded for 
viewing with a viewer program on the mobile client device. 
In one embodiment, an executable version of a process, 
including the code and data for executing the process, may 
be downloaded for execution on the mobile client device. In 
one embodiment, the service may execute the application 
remotely on behalf of the mobile client device, and the 
service and client may pass to each other XML messages 
including data and optionally XML schemas describing the 
data. In one embodiment, some code may be executed on the 
service and some on the client. For example, the service may 
execute code to perform operations on a set of data such as 
numerical calculations. The mobile client device may 
execute code that may display portions of the data passed to 
the client from the service in XML messages and allow the 
user of the mobile client device to enter and/or select data 
and send the data to the service for performing one or more 
operations on the data. 

In one embodiment, a mobile client device may be 
connected to two or more services in the distributed com- 
puting network simultaneously. The services may be used 
independently or in conjunction for performing a series of 
tasks. For example, one service may be used by a remote 
client device to locate and/or perform operations on a set of 
data, and a second service may be used to print the set of 
data. 

FIG. 38 illustrates a mobile client device accessing spaces 
in a local distributed computing network, according to one 
embodiment. A user of GPS-enabled mobile computing 
device 1700 may move into proximity of a local distributed 
computing environment. The mobile client device 1700 may 
provide its location provided by GPS 1702 to one or more 
discovery mechanisms 1706 in the local distributed com- 
puting network. The discovery mechanism 1706 may use the 
provided GPS location of the mobile client device and 
predetermined locations of spaces within the environment to 
determine when the user moves within a specified range of 
one or more spaces or a vicinity served by one or more 
spaces within the environment. For example, discovery 
mechanism 1706 may determine that mobile client device 
1700 has moved within range of space 1704. Discovery 
mechanism 1706 may then provide one or more advertise- 
ments 1710 from space 1704 to the mobile client device 
1700. Alternatively, discovery mechanism 1706 may pro- 
vide a Universal Resource Identifier (URI) for space 1704, 
or for one or more advertisements in space 1704, to mobile 
client device 1700. Icons representing the various services 
advertised by service advertisements 1708 and/or data rep- 
resented by content advertisements 1710 may then be dis- 
played on mobile client device 1700. The user may then 
select one or more of the advertised services and/or data for 
execution and/or display on the mobile client device. The 
mobile computing device 1700 may establish a wireless 
connection with the device offering the service and com- 
municate with the device to execute the service using the 
XML-based messaging system as previously described 
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herein. Alternatively, the user of the mobile computing 
device 1700 may connect the device at a docking station. 
The location of the docking station may have been discov- 
ered by the user using the lookup or discovery mechanism 
1706, and spaces containing advertisements for the docking 
stations to discover the location and availability of docking 
stations within a specified range of the user. 

Discovery mechanism 1706 may also detect when mobile 
client device 1700 moves into a selected range of space 
1714. The various service advertisements 1718 and content 
advertisements 1720 may then be made available to the user 
of the mobile client device 1700. When the mobile client 
device moves out of the specified range of one of the spaces, 
the advertisements offered by that space may be removed 
from the mobile client device 1700' s display. 

In one embodiment, advertisements on a space may 
include location information for the services or data that 
they provide. Thus, discovery mechanism 1706 may deter- 
mine when mobile client device 1700 moves within a 
specified range of a particular service advertised on space 
1718, and may provide (or remove) the service advertise- 
ment based upon the location of the mobile client device 
1700. 

Computing devices are shrinking while at the same time 
gaining power and functionality. Storage devices, CPUs, 
RAM, I/O ASICS, power supplies, etc. have been reduced in 
size to where small, mobile client devices may include much 
of the functionality of a full -sized personal computer. 
However, some components of a computer system are not 
easily shrinkable because of the human factor and other 
factors. These components include, but are not limited to: 
keyboards, monitors, scanners, and printers. The limits on 
reducing the size of some components may prevent mobile 
client devices from truly assuming the role of personal 
computers. 

In one embodiment, docking stations may be provided 
that allow users with mobile client devices to connect to and 
use components that are not available on the mobile client 
device because of human or other factors. For example, 
docking stations may be provided in public places such as 
airports or libraries. The docking stations may provide 
monitors, keyboards, printers or other devices for users with 
mobile client devices. In one embodiment, the docking 
stations may not fully function without help from a real 
computing device such as a mobile client device connected 
by a user. The docking station may provide services such as 
various input/output functions to the client using the com- 
puting power of the mobile client device. 

A docking station may provide one or more connection 
options to a mobile client device. The connection options 
may include wireless connections and wired connections. 
Examples of wireless connections include, but are not lim- 
ited to: infrared such as IrDA and wireless network connec- 
tions similar to those provided by a network interface card 
(NIC) in a notebook computer. Examples of wired connec- 
tions include, but are not limited to: USB, FireWire, and 
twisted-pair Ethernet. 

A mobile client device may discover the location of 
docking stations using a method substantially similar to that 
described above for mobile client devices. The location of 
one or more docking stations in a local distributed comput- 
ing network may be discovered using a discovery mecha- 
nism to discover spaces with advertisements for docking 
stations. The mobile client device may provide a location to 
the discovery mechanism. In one embodiment, the discovery 
mechanism or a lookup mechanism may return the location 
of one or more docking stations closest to the location of the 
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mobile client device. Alternatively, the discovery mecha- 
nism or lookup mechanism may return a URI of the space 
containing the advertisements for the docking stations, and 
the mobile client device may then connect with the space to 

5 provide the location of the one or more docking stations near 
the device. In one embodiment, the mobile client device may 
supply information to the lookup or discovery mechanism to 
specify requirements such as monitor resolution, screen size, 
graphics capabilities, available devices such as printers and 

10 scanners, etc. In one embodiment, information about the one 
or more docking stations may be supplied to the user on the 
mobile client device including availability (is another user 
using the docking station), components and capabilities of 
the various docking stations. 

15 When a user approaches a docking station, a claiming 
protocol may be initiated. When the claim is accepted by the 
docking station, secure input and output connections may be 
established between the mobile client device and the dock- 
ing station. Alternatively, the user may select the docking 

20 station from one or more docking stations discovered using 
the lookup or discovery mechanism displayed on the mobile 
client device. When the user selects the docking station, the 
claiming protocol may be initiated to give the user secure, 
exclusive connection to the docking station for the duration 

25 of the claim. A docking station release method may also be 
provided to allow the user to terminate the session on the 
docking station and release the docking station for use by 
other users. In one embodiment, the claiming protocol may 
be a lease on the docking station service as described 

30 previously herein. 

FIG. 39a illustrates a user of a mobile device discovering 
the location of docking stations according to one embodi- 
ment. 

FIG. 39b illustrates a mobile client device 1750 connect- 
35 ing to a docking station 1760, according to one embodiment. 
In one embodiment, a user may connect a mobile client 
device to a docking station without using the discovery 
mechanism. For example, a user in an airport may visually 
detect a docking station and connect a mobile client device 
40 to it. Another example may be a library providing a docking 
station room with a plurality of docking stations for use, 
where users may access any of the docking stations that are 
available. 

Small Footprint and/or Embedded Devices 

45 Simple embedded or small footprint devices may have 
limited amounts of memory for storing and executing pro- 
gram instructions. A simple embedded device may need to 
understand a limited set of control inputs for initiating 
functionality of the device and outputs for reporting the 

50 status of the device. An example of a simple embedded 
device is a "smart" switch (such as a light switch) with 
embedded circuitry for controlling the switch and thus the 
device controlled by the switch. The smart switch may only 
need to understand two control requests (change the state of 

55 the device, request the state of the device) and to send one 
status message (the state of the device). The smart switch 
may manage the device to which it is connected by receiving 
its control requests from one or more control systems and 
reporting status messages to the one or more control sys- 

60 terns. 

In one embodiment, the distributed computing environ- 
ment may provide a framework (protocol) for including 
small devices that may not have the resource footprint (such 
as memory) necessary to implement the full protocol of the 
65 distributed computing environment. In one embodiment, an 
agent may be provided as a bridge between the small 
device-capable protocol and the full protocol. The agent may 
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perform the full protocol discovery for the small device, so 
the device may not be required to implement the full 
discovery protocol and service activation. In one 
embodiment, the small device may only need to send 
service-specific messages. In one embodiment, these mes- s 
sages may be pre-cooked on the small device, so the small 
device may only have to send messages that are part of the 
service activation to the agent. The agent may perform the 
service activation via the full protocol to the service and 
forward incoming message from the device to the service, 10 
and/or may forward replies from the service to the client. 
Thus, the agent may act as a service connector for the small 
client. 

In one embodiment of the distributed computing 
environment, an embedded device may be configured to is 
receive a specific set of control requests in the form of XML 
messages, and to send a specific set of XML messages to 
make requests, report status, etc. In one embodiment, a 
control system may be configured to manage a variety of 
devices by sending XML request messages specific to each 20 
device or category of device that it controls and by receiving 
XML messages from the devices. In one embodiment, one 
or more XML schemas may be used to define an embedded 
device's specific set of XML messages; the schema may be 
used by the embedded device and/or the control system in 25 
sending and receiving XML messages. 

An embedded device may include a "thin" implementa- 
tion of the XML messaging system as previously described 
herein that supports the specific set of messages for con- 
trolling and monitoring the simple embedded device. The 30 
implementation of the XML messaging system may be 
tailored for use with small footprint, simple embedded 
devices, and thus may fit in the limited memory of the small 
footprint devices. In one embodiment, the XML messaging 
system may be implemented in a small footprint with a 35 
virtual machine targeted at small footprint embedded 
devices (e.g. KVM). A networking stack (to support the 
transport protocol for communications with one or more 
control systems) may be associated with the virtual machine 
and the XML messaging layer may "sit on top" of the 40 
networking stack. It is noted that this implementation of the 
messaging system may be used in other devices than small 
footprint or embedded devices. 

In one embodiment, static or pre-generated messages may 
be used for requests from control systems to embedded 45 
devices. The static messages may be precompiled and stored 
in the embedded devices. An incoming message may be 
compared with the stored static messages to find a match for 
the message and thus to perform the function requested by 
the message, thus reducing or eliminating the need for code 50 
to parse incoming messages. Outgoing messages may be 
read directly from the stored static messages, thus reducing 
or eliminating the need to dynamically compile outgoing 
messages. Thus, static messages may be used to reduce the 
code footprint of the messaging layer in embedded systems. 55 
For example, static Java objects (Java op codes) may be used 
for request and status messages. 

FIG. 40a illustrates an embodiment of embedded devices 
1804a and 18046 controlled by a control system 1800, 
according to one embodiment. Control system 1800 may be 60 
networked with the devices 1804a and 18046 it controls in 
any of a variety of ways. The network 1810 may be wired 
(Ethernet, coaxial, twisted pair, power grid, etc.) and/or 
wireless (IrDA, microwave, etc.). In one embodiment, 
embedded devices 1804a and 18046 may include a thin 65 
implementation of the XML messaging system for commu- 
nicating with control system 1800 over network 1810. 
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Control system 1800 may have an Implementation of the 
XML messaging system for sending requests to and receiv- 
ing responses from embedded devices 1804a and 18046. In 
one embodiment, control system 1800 may include software 
and hardware configured to present an interface to allow a 
user to display the status of and remotely control the 
embedded devices 1804a and 18046. In one embodiment, 
control system 1800 may include software and/or hardware 
for automatic control of embedded devices 1804a and 
18046. 

In one embodiment, embedded devices 1804a and 18046 
may be part of another environment. The devices may not 
support the message passing model implemented by the 
distributed network environment. For example, the devices 
may be nodes in a networked automation and control system 
such as a LonWorks network. Control system 1800 may 
include a control system hardware and/or software for 
controlling devices in the other environment. Control system 
1800 may serve as a bridge between the distributed com- 
puting environment and the other environment. The distrib- 
uted computing environment may also provide a method or 
methods to wrap existing device discovery protocols for 
discovering the devices for access from the distributed 
network environment. Bridging and wrapping protocols are 
further described herein in the Bridging section. 

Control system 1800 may be connected remotely or 
locally to one or more other systems in the distributed 
computing environment. FIG. 40a shows control system 
1800 connected to client 1806 via the Internet 1802. Client 
1806 may indirectly request the status of, and send control 
requests to, embedded devices 1804a and 18046 through 
control system 1800. Thus, control system 1800 may serve 
as a proxy or bridge for embedded devices 1804a and 18046. 
See the Bridging section herein. To enable sophisticated 
communication between the client 1806 and the control 
system 1800, the client and the control system may have 
different implementations of the XML messaging system 
than the thin implementation on the embedded devices 
1804a and 18046. In one embodiment, client 1806 may 
include software and hardware configured to present an 
interface to allow a user of client 1806 to display the status 
of and remotely control the embedded devices 1804a and 
18046. In one embodiment, client 1806 must present the 
correct authorization credentials to control system 1800 to 
enable the client 1806 to access embedded devices 1804a 
and 18046. In one embodiment, client 1806 may be granted 
access at different levels. For example, client 1806 may only 
be able to view the status of embedded devices 1804a and 
18046 but not be allowed to remotely control the devices. In 
one embodiment, control system 1800 may be a service, 
may have a service advertisement published in the distrib- 
uted computing environment, and thus may be accessed by 
client 1806 using the client-service method as described 
previously in this document. In one embodiment, client 1806 
may be able to view the status of, and to remotely control, 
control system 1800. 

FIG. 406 illustrates client control system 1808 connected 
via the Internet 1802 to embedded devices 1804c and 1804a*, 
according to one embodiment. In one embodiment, embed- 
ded devices 1804c and 1804a* may include a thin implemen- 
tation of the XML messaging system for communicating 
with client control system 1808 over the Internet 1802. 
Client control system 1808 may have an implementation of 
the XML messaging system for sending requests to and 
receiving responses from embedded devices 1804c and 
1804a*. In one embodiment, client control system 1808 may 
include software and hardware configured to present an 
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interface to allow a user to display the status of and remotely 
control the embedded devices 1804c and 1804d. In one 
embodiment, client control system 1800 may include soft- 
ware and/or hardware for automatic control of embedded 
devices 1804c and 1804rf. 

Adifference between FIG. 40a and FIG. 406 is that, in the 
embodiment illustrated in FIG. 40b, the embedded devices 
1804c and 1804d may be accessed by one or more clients in 
the distributed computing environment without requiring a 
proxy (e.g. control system). Embedded devices 1804c and 
lS04d may include services for accessing the functionality 
of the devices, may have published service advertisements 
in the distributed computing environment, and thus may be 
accessed via the client-service method as described previ- 
ously in this document. 

The distributed computing environment may include a 
mechanism for a resource-limited client to retrieve Univer- 
sal Resource Identifier (URI) addressed resources. For 
example, a client that is only capable of sending and 
receiving messages via an IrDA connection may not be able 
to establish a URI connection to retrieve results from a 
results space. In one embodiment, a service may be provided 
as a bridge between the client and the URI resource. The 
bridge service may interact with the client via XML mes- 
sages to gather input parameters. The following is included 
as an example of an XML input message syntax and is not 
intended to be limiting in any way: 

<type name="HttpGet"> 

<element name="urlstring"type="string*V> 

</type> 

Then, outside the distributed computing environment, the 
bridge service may establish a URI connection and retrieve 
the resource. The resource may then be encapsulated as a 
payload in one or more XML messages and sent to the client 
by the bridge service. 

The following illustration of one possible use of embed- 
ded devices with thin implementations of the XML messag- 
ing system is included for exemplary purposes and is not 
intended to be limiting. A building may include a plurality 
of electronic devices that consume energy (e.g. lights, air 
conditioners, office equipment), and thus may require a 
system for maintaining an optimum energy consumption 
level. The plurality of devices may each include an embed- 
ded device for controlling the electronic devices. The 
embedded devices may include the thin implementation of 
the XML messaging system. One or more control systems 
may be coupled to the devices in a network, for example, a 
building LAN or even the Internet, A control system may 
store and execute a building management software package 
and an implementation of the XML messaging system 
configured to be used by the software package for monitor- 
ing and controlling the devices. The control system may 
accept input from users, and may display and otherwise 
output status information for the building energy consump- 
tion system, including status information for each of the 
plurality of devices. Energy consumption may be monitored 
by receiving XML status messages from each of the plurality 
of devices. When energy consumption levels need to be 
adjusted, XML control messages may be sent to one or more 
of the devices to cause the energy consumption to change. 
Implementing Services 

In one embodiment, the distributed computing environ- 
ment may provide a mechanism for implementing services 
as serviets. The mechanism may provide functionality for 
developing services for the distributed computing environ- 
ment. 

In one embodiment, an Application Programming Inter- 
face (API) may be provided that provides the functionality 
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to allow the service to be initialized and registered in a 
space. In one embodiment, the API may be used to invoke 
the initialization of the service and to generate an initializa- 
tion status page, for example, an HTML page, that may 
define the status of the service. A user may access the status 
of the service by accessing the status page from a browser. 
In one embodiment, the API may be used to process incom- 
ing messages and to generate documents in response to the 
messages. 

An embodiment of the servlet mechanism may provide 
several functions including, but not limited to: 

Management of the client connection to the service 

(unique session ID) 
Management of an activation space that may be used to 

store results advertisements 
Management of leases on connections sessions and results 

in activation spaces 
Garbage collection of sessions and results 
Authentication of clients 

Generation of client capabilities on a per session basis 
Conclusion 

Various embodiments may further include receiving or 
storing instructions and/or data implemented in accordance 
with the foregoing description upon a carrier medium. 
Suitable carrier media may include storage media or 
memory media such as magnetic or optical media, e.g., disk 
or CD-ROM, as well as transmission media or signals such 
as electrical, electromagnetic, or digital signals, conveyed 
30 via a communication medium such as network and/or a 
wireless link. 

Various modifications and changes may be made as would 
be obvious to a person skilled in the art having the benefit 
of this disclosure. It is intended that the invention embraces 
all such modifications and changes and, accordingly, the 
specifications, appendices and drawings are to be regarded 
in an illustrative rather than a restrictive sense. 
What is claimed is: 

1. A method, comprising: 

a client sending a lookup message to a network- 
addressable location of a space, wherein the space is 
operable to store one or more advertisements expressed 
in a data representation language, wherein each adver- 
tisement comprises information which is usable by the 
client to access a particular content or service over a 
network, and wherein the lookup message specifies 
desired advertisement characteristics; 
finding a set of discovered advertisements, wherein the 
discovered advertisements comprise zero or more of 
the stored advertisements which meet the desired char- 
acteristics; and 
the space sending a lookup response message to the client, 
wherein the lookup response message comprises the set 
of discovered advertisements. 

2. The method of claim 1, 

wherein each advertisement comprises a Uniform 
Resource Identifier (URI) at which the respective con- 
tent or service is accessible. 

3. The method of claim 1, 

wherein at least one of the discovered advertisements 
comprises an advertisement for a service. 

4. The method of claim 3, 

wherein the advertisement for the service comprises a 
schema, wherein the schema specifies one or more 
messages usable to invoke one or more functions of the 
service. 
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5. The method of claim 1, 

wherein the lookup message comprises a desired name, 
wherein each of the discovered advertisements com- 
prises a name that matches the desired name, and 
wherein each name identifies the respective discovered 5 
advertisement within space. 

6. The method of claim 5, 

wherein the desired name comprises a wildcard. 

7. The method of claim 1, 1Q 
wherein the lookup message comprises a desired schema 

which is expressed in the data representation language, 
and wherein each of the discovered advertisements 
comprises a schema that matches the desired schema. 

8. The method of claim 1, 3 5 
wherein the lookup message comprises a desired name 

and a desired schema, wherein the set of discovered 
advertisements comprises discovered advertisements 
having a name that matches the desired name and 
discovered advertisements having a schema that 20 
matches the desired schema. 

9. The method of claim 1, 

wherein the lookup message comprises a request for all 
advertisements in the space, and wherein the set of 
discovered advertisements includes substantially all the 25 
stored advertisements. 

10. The method of claim 1, 

wherein the data representation language comprises 
extensible Markup Language (XML). 

11. The method of claim 1, 30 
wherein the lookup message and the lookup response 

message are expressed in the data representation lan- 
guage, 

12. A system, comprising: 35 
a client; and 

a space which is communicatively coupled to the client, 
wherein the space is operable to store one or more 
advertisements expressed in a data representation 
language, wherein each advertisement comprises infor- 40 
mauon which is usable by the client to access a 
particular content or service over a network; 
wherein the client is operable to send a lookup message to 
the space, and wherein the lookup message specifies 
desired advertisement characteristics; and 45 
wherein the space is operable to: 

find a set of discovered advertisements, wherein the 
discovered advertisements comprise zero or more of 
the stored advertisements which meet the desired 
characteristics; and 50 
send a lookup response message to the client, wherein 
the lookup response message comprises the set of 
discovered advertisements. 

13. The system of claim 12, 

wherein each advertisement comprises a Uniform 
Resource Identifier (URI) at which the respective con- 
tent or service is accessible. 

14. The system of claim 12, further comprising: 

a service which is communicatively coupled to the client, 60 
wherein at least one of the discovered advertisements 
comprises an advertisement for the service. 

15. The system of claim 14, 

wherein the advertisement for the service comprises a 
schema, wherein the schema specifies one or more 65 
messages usable to invoke one or more functions of the 
service. 
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16. The system of claim 12, 

wherein the lookup message comprises a desired name, 
wherein each of the discovered advertisements com- 
prises a name that matches the desired name, and 
wherein each name identifies the respective discovered 
advertisements within the space. 

17. The system of claim 16, 

wherein the desired name comprises a wildcard. 

18. The system of claim 12, 

wherein the lookup message comprises a desired schema 
which is expressed in the data representation language, 
and wherein each of the discovered advertisements 
comprises a schema that matches the desired schema. 

19. The system of claim 12, 

wherein the lookup message comprises a desired name 
and a desired schema, wherein the set of discovered 
advertisements comprises discovered advertisements 
having a name that matches the desired name and 
discovered advertisements having a schema that 
matches the desired schema. 

20. The system of claim 12, 

wherein the lookup message comprises a request for all 
advertisements in the space, and wherein the set of 
discovered advertisements includes substantially all the 
stored advertisements. 

21. The system of claim 12, 

wherein the data representation language comprises 
extensible Markup Language (XML). 

22. The system of claim 12, 

wherein the lookup message and the lookup response 
message are expressed in the data representation lan- 
guage. 

23. A carrier medium comprising program instructions, 
wherein 

the program instructions are computer-executable to 
implement: 

a client sending a lookup message to a network- 
addressable location of a space, wherein the space is 
operable to store one or more advertisements 
expressed in a data representation language, wherein 
each advertisement comprises information which is 
usable by the client to access a particular content or 
service over a network, and wherein the lookup 
message specifies desired advertisement characteris- 
tics; 

finding a set of discovered advertisements, wherein the 
discovered advertisements comprise zero or more of 
the stored advertisements which meet the desired char- 
acteristics; and 

the space sending a lookup response message to the client, 
wherein the lookup response message comprises the set 
of discovered advertisements. 

24. The carrier medium of claim 23, 

wherein each advertisement comprises a Uniform 
Resource Identifier (URI) at which the respective con- 
tent or service is accessible. 

25. The carrier medium of claim 23, 

wherein at least one of the discovered advertisements 
comprises an advertisement for a service. 

26. The carrier medium of claim 25, 

wherein the advertisement for the service comprises a 
schema, wherein the schema specifies one or more 
messages usable to invoke one or more functions of the 
service. 
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27. The carrier medium of claim 23, 
wherein the lookup message comprises a desired name, 

wherein each of the discovered advertisements com- 
prises a name that matches the desired name, and 
wherein each name identifies the respective discovered 5 
advertisements within the space. 

28. The carrier medium of claim 27, 
wherein the desired name comprises a wildcard. 

29. The carrier medium of claim 23, 

10 

wherein the lookup message comprises a desired schema 
which is expressed in the data representation language, 
and wherein each of the discovered advertisements 
comprises a schema that matches the desired schema. 

30. The carrier medium of claim 23, 
wherein the lookup message comprises a desired name 

and a desired schema, wherein the set of discovered 
advertisements comprises discovered advertisements 
having a name that matches the desired name and 
discovered advertisements having a schema that 2 o 
matches the desired schema. 

31. The carrier medium of claim 23, 
wherein the lookup message comprises a request for all 

advertisements in the space, and wherein the set of 
discovered advertisements includes substantially all the 25 
stored advertisements. 

32. The carrier medium of claim 23, 
wherein the data representation language comprises 

extensible Markup Language (XML). 

33. The carrier medium of claim 23, 30 
wherein the lookup message and the lookup response 

message are expressed in the data representation lan- 
guage. 

34. A method, comprising: 

a client sending a lookup message to a space, wherein the 
lookup message is expressed in a data representation 
language, wherein the space is operable to store one or 
more documents expressed in the data representation 
language, and wherein the lookup message specifies 4Q 
desired characteristics of the stored documents; 

finding a set of discovered documents, wherein the dis- 
covered documents comprise zero or more of the stored 
documents which meet the desired characteristics; and 

the space sending a lookup response message to the client, 45 
wherein the lookup response message is expressed in 
the data representation language and comprises the set 
of discovered documents. 

35. The method of claim 34, 

wherein each of the discovered documents comprises 50 
information usable by the client to access a respective 
content or service. 

36. The method of claim 35, 

wherein the information usable by the client to access a 
respective content or service comprises a Uniform 
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Resource Identifier (URI) at which the respective con- 
tent or service is accessible. 

37. The method of claim 35, 

wherein at least one of the discovered documents com- 
prises information for accessing a service. 

38. The method of claim 37, 

wherein the information for accessing a service comprises 
a schema, wherein the schema specifies one or more 
messages usable to invoke one or more functions of the 
service. 

39. The method of claim 34, 

wherein the lookup message comprises a desired name, 
wherein each of the discovered documents comprises a 
name that matches the desired name, and wherein each 
name identifies the respective discovered document 
within the space. 

40. The method of claim 39, 

wherein the desired name comprises a wildcard. 

41. The method of claim 34, 

wherein the lookup message comprises a desired schema 
which is expressed in the data representation language, 
and wherein each of the discovered documents com- 
prises a schema that matches the desired schema. 

42. The method of claim 34, 

wherein the lookup message comprises a desired name 
and a desired schema, wherein the set of discovered 
documents comprises discovered documents having a 
name that matches the desired name and discovered 
documents having a schema that matches the desired 
schema. 

43. The method of claim 34, 

wherein the lookup message comprises a request for all 
documents in the space, and wherein the set of discov- 
ered documents includes substantially all the stored 
documents. 

44. The method of claim 34, 

wherein the data representation language comprises 
extensible Markup Language (XML). 

45. The method of claim 34, further comprising: 

the client sending an event subscription message to the 
space, wherein the event subscription message indi- 
cates a desired document for which the client is 
requesting to receive notification if the desired docu- 
ment is added to or removed from the space; and 

the space sending an event notification message to the 
client when a document matching the desired document 
is added to or removed from the space. 

46. The method of claim 45, wherein the event subscrip- 
tion message and the event notification message are 
expressed in the data representation language. 

***** 
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